<div dir="ltr">Hi,<div><br></div><div>as promised, I've managed to compile this OWS Context schema:</div><div><br></div><div><a href="https://github.com/highsource/ogc-schemas/tree/master/owc/0.3.1">https://github.com/highsource/ogc-schemas/tree/master/owc/0.3.1</a><br>
</div><div><br></div><div>Was indeed a bit tricky. I had to compile SLD 1.0.0, KML 2.2.0, Atom and xAL first. :)</div><div><br></div><div>I've noticed is that these schemas (KML, SLD etc.( are required for the mappings to work since they are indeed used for inlining. This is a problem since one kml:Document reference adds three further dependencies and will be most probably not be necessary.</div>
<div><br></div><div>I've customized OWS Context schema to "lax" the kml:Document reference:</div><div><br></div><div><div><span class="" style="white-space:pre"> </span><jaxb:bindings node="xs:complexType[@name='LayerType']//xs:element[@ref='kml:Document']"></div>
<div><span class="" style="white-space:pre"> </span><xjc:dom/></div><div><span class="" style="white-space:pre"> </span><wildcard:lax/></div><div><span class="" style="white-space:pre"> </span></jaxb:bindings></div>
</div><div><br></div><div>This maps the "document" property to a "lax any element". That is, if you'll get a kml:Document in the XML and don't have the KML_2_2_0 in your context then you'll get a DOM element. If you do have KML 2_2_0 in your context, the kml:Document will be parsed.</div>
<div><br></div><div>Since the approach above is somewhat limited (you can only have at most one "any element" property per type) I only removed the KML dependencies so far.</div><div>Here's how it look in the test:</div>
<div><br></div><div><a href="https://github.com/highsource/ogc-schemas/blob/master/scripts/tests/OWC/0.3.1/OWC_0_3_1.js">https://github.com/highsource/ogc-schemas/blob/master/scripts/tests/OWC/0.3.1/OWC_0_3_1.js</a><br></div>
<div><br></div><div><div>var context = new Jsonix.Context([XLink_1_0, OWS_1_0_0, Filter_1_0_0, GML_2_1_2, SLD_1_0_0, OWC_0_3_1]);</div><div>var unmarshaller = context.createUnmarshaller();</div><div>unmarshaller.unmarshalFile("tests/OWC/0.3.1/example-owcContext.xml", function(result) {</div>
<div><span class="" style="white-space:pre"> </span>console.log(result.value.resourceList.layer[0].server[0].onlineResource[0].href);</div><div><span class="" style="white-space:pre"> </span>test.equal("<a href="http://sigma.openplans.org:8080/geoserver/wms?SERVICE=WMS">http://sigma.openplans.org:8080/geoserver/wms?SERVICE=WMS</a>", result.value.resourceList.layer[0].server[0].onlineResource[0].href);</div>
<div><span class="" style="white-space:pre"> </span>test.done();</div><div>});</div></div><div><br></div><div>I'll implement a customization which would allow to lax any property. This will be a method to avoid hard dependencies to other schemas. You actually don't have an absolute necessity for Filter_1_0_0 and GML 2_1_2, this can be avoided.</div>
<div><br></div><div>I'll write a short manual on schema compilation later on. There was a dozen of problems I ran into when doing this schema.</div><div><br></div><div>I also plan to cut the mappings file size dramatically. Field names can be safely shortened, this might bring at least 50% cut. Further features like compiling only what you need for a specific case and making hard dependencies between schemas optional are also quite easy to implement and will help a lot.</div>
<div><br></div><div>Best wishes,</div><div>Alexey</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 5:58 PM, Aleksei Valikov <span dir="ltr"><<a href="mailto:aleksei.valikov@gmail.com" target="_blank">aleksei.valikov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
ok, understood. Let me compile it for you. If you have a couple of test documents, could you please send them to me so that I could also do the tests?<br>
<br>
Compiling schemas is a bit tricky. Most OGC schemas suffer from one or the other problem. You have to resolve naming collisions and so on.<br>
Finally, the libs behind Jsonix compiler also have quite a few issues. Everything is solveable but you need experience to do that.<br>
<br>
I'd gladly overtake compilation of schemas you guys need. Just tell me, which schemas.<br>
<br>
Best wishes,<br>
Alexey<br>
<br>
> Am 03.09.2014 um 16:44 schrieb Pierre Giraud <<a href="mailto:pierre.giraud@camptocamp.com">pierre.giraud@camptocamp.com</a>>:<br>
<div class="HOEnZb"><div class="h5">><br>
> Hello,<br>
><br>
> I'm Pierre GIRAUD. I work with Éric at camptocamp.<br>
><br>
><br>
><br>
>> On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <<a href="mailto:valikov@gmx.net">valikov@gmx.net</a>> wrote:<br>
>> Hi Eric,<br>
>><br>
>> the first problem is trivial:<br>
>><br>
>> <a href="http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd" target="_blank">http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd</a><br>
>><br>
>> does not longer exist.<br>
>><br>
>><br>
>><br>
>> The second problem is due to the fact that the xlinks schema defines some<br>
>> properties which map onto the same name "title". This mus be customized to<br>
>> avoid naming collission.<br>
>><br>
>> Here's the customization I use:<br>
>><br>
>> <a href="https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/binding.xjb" target="_blank">https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/binding.xjb</a><br>
>><br>
>> It is also recommended to save the schema locally and to "redirect" the URL<br>
>> to that location using a catalog file:<br>
>><br>
>> <a href="https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/catalog.cat" target="_blank">https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/catalog.cat</a><br>
>><br>
>> So you'll finally end up with a CLI command like:<br>
>><br>
>> java -jar jsonix-schema-compiler-full.jar -catalog <a href="http://catalog.cat" target="_blank">catalog.cat</a> -b<br>
>> bindings.xjb -extension owsContext.xsd.<br>
><br>
> We'll give it a try unless you've already done it yourself.<br>
>><br>
>><br>
>> But I hope you won't need to compile schema at all. My hope is that you<br>
>> could just reuse the standard mappings from ogc-schemas project.<br>
>><br>
>> By the way the ows schemas are already compiled:<br>
>><br>
>> <a href="https://github.com/highsource/ogc-schemas/tree/master/ows" target="_blank">https://github.com/highsource/ogc-schemas/tree/master/ows</a><br>
>> <a href="https://github.com/highsource/ogc-schemas/tree/master/scripts/lib" target="_blank">https://github.com/highsource/ogc-schemas/tree/master/scripts/lib</a><br>
><br>
> Unfortunately, OWS (common) is different from OWS Context.<br>
><br>
>><br>
>> (I'll add a test later on.)<br>
>><br>
>> Any reason you need the 0.3.1 version specifically? I mean, it's no big deal<br>
>> compiling that version but isn't it a bit outdated?<br>
><br>
> We already know that 0.3.1 is outdated. For an unknown reason we<br>
> cannot find any information about it on the OGC website.<br>
> However we still have documents to parse using this schema. The idea<br>
> is to migrate an application from OpenLayers 2 (in which a OWSContext<br>
> Format exists) to OpenLayers 3 and keep things running correctly.<br>
><br>
> Regards,<br>
> Pierre<br>
><br>
><br>
>><br>
>><br>
>><br>
>> I'll be checking the Closure Compiler. Closure-compiling Jsonix runtime<br>
>> should not be a problem. We've an extended set of tests to check whether the<br>
>> compiled library would behave correctly.<br>
>><br>
>> As for closure-compiling the mapping files - I don't think that this would<br>
>> bring anything (apart from some minification). I don't think that Closure<br>
>> Compiler will be the right approach for mappings. Best results can be<br>
>> achieved when you know the subset of the schema you need - or a subset of<br>
>> the schema you don't need - and compile exactly the required subset. So you<br>
>> could get the tiny GML_3_1_1_Geometries instead of the huge GML_3_1_1.<br>
>> I doubt that Closure Compiler will be able to do this reasonably.<br>
>> But this can be a quite-an-easy to implement feature in Jsonix itself. You'd<br>
>> just list the elements and types you need (or explicitly list things you<br>
>> don't need) and Jsonix would generate a partial mapping. This will be a<br>
>> subset of the whole mapping - fully upwards compatible (you could alway<br>
>> replace GML_3_1_1_Geometries with the full GML_3_1_1).<br>
>><br>
>> You can surely minify the mappings with Closure Compiler afterwards.<br>
>><br>
>> Best wishes,<br>
>> Alexey<br>
>><br>
>><br>
>> On Wed, Sep 3, 2014 at 3:02 PM, Eric Lemoine <<a href="mailto:eric.lemoine@camptocamp.com">eric.lemoine@camptocamp.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Aleksei<br>
>>><br>
>>> Great work on jsonix and ogc-schemas!<br>
>>><br>
>>> At Camptocamp we've tried to use jsonix for OWSContext 0.3.1 :<br>
>>> <<a href="http://www.ogcnetwork.net/schemas/owc/0.3.1/owsContext.xsd" target="_blank">http://www.ogcnetwork.net/schemas/owc/0.3.1/owsContext.xsd</a>>. But<br>
>>> we've had problems. When reading the owsContext.xsd file without any<br>
>>> modification, we get the following error at:<br>
>>><br>
>>> ------------------<br>
>>> $ java -jar jsonix-schema-compiler-full-2.0.0.jar -d /tmp/owscontext<br>
>>> owsContext.xsd<br>
>>> [WARNING] schema_reference.4: Failed to read schema document<br>
>>> '<a href="http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd" target="_blank">http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd</a>', because 1) could<br>
>>> not find the document; 2) the document could not be read; 3) the root<br>
>>> element of the document is not <xsd:schema>.<br>
>>> ------------------<br>
>>><br>
>>> This first error seems to be related to the fact that the xlink xsd<br>
>>> was archived on OpenGIS. See<br>
>>> <<a href="http://schemas.opengis.net/xlink/ReadMe.txt" target="_blank">http://schemas.opengis.net/xlink/ReadMe.txt</a>>. After removing the<br>
>>> corresponding xs:import line from the owsContext.xsd file we get the<br>
>>> following new errors:<br>
>>><br>
>>> ------------------<br>
>>> $ java -jar jsonix-schema-compiler-full-2.0.0.jar -d /tmp/owscontext<br>
>>> owsContext.xsd<br>
>>> [ERROR] Property "Title" is already defined. Use <jaxb:property> to<br>
>>> resolve this conflict.<br>
>>> line 232 of <a href="http://www.w3.org/1999/xlink.xsd" target="_blank">http://www.w3.org/1999/xlink.xsd</a><br>
>>><br>
>>> [ERROR] The following location is relevant to the above error<br>
>>> line 219 of <a href="http://www.w3.org/1999/xlink.xsd" target="_blank">http://www.w3.org/1999/xlink.xsd</a><br>
>>><br>
>>> [ERROR] Property "Title" is already defined. Use <jaxb:property> to<br>
>>> resolve this conflict.<br>
>>> line 261 of <a href="http://www.w3.org/1999/xlink.xsd" target="_blank">http://www.w3.org/1999/xlink.xsd</a><br>
>>><br>
>>> [ERROR] The following location is relevant to the above error<br>
>>> line 246 of <a href="http://www.w3.org/1999/xlink.xsd" target="_blank">http://www.w3.org/1999/xlink.xsd</a><br>
>>><br>
>>> Exception in thread "main" java.lang.NullPointerException<br>
>>> at<br>
>>> org.jvnet.jaxb2_commons.util.CustomizationUtils.getCustomizations(CustomizationUtils.java:475)<br>
>>> at<br>
>>> org.jvnet.jaxb2_commons.util.CustomizationUtils.findCustomizations(CustomizationUtils.java:247)<br>
>>> at org.hisrc.jsonix.JsonixMain.execute(JsonixMain.java:113)<br>
>>> at org.hisrc.jsonix.JsonixMain.main(JsonixMain.java:92)<br>
>>> ------------------<br>
>>><br>
>>> Do you know why we have these errors? Would you agree to try the<br>
>>> owsContext.xsd file yourself? If it works the resulting js file could<br>
>>> possibly be added to ogc-schemas.<br>
>>><br>
>>> Also, thanks a lot for the answers you provided to my questions. They<br>
>>> all make sense to me. As I said I'd be very interested to be able to<br>
>>> compile (with Closure Compiler) both the Jsonix library and the<br>
>>> ogc-schemas scripts. But I still need to investigate how feasible this<br>
>>> is. I hope to have a look at this.<br>
>>><br>
>>> Thanks for lot, and thanks in advance for looking at the OWSContext.xsd<br>
>>> file!<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>> On Wed, Sep 3, 2014 at 9:21 AM, Aleksei Valikov <<a href="mailto:valikov@gmx.net">valikov@gmx.net</a>> wrote:<br>
>>>> Hi,<br>
>>>><br>
>>>> here's a short update on the Jsonix progress in the last days.<br>
>>>><br>
>>>> We've started the OGC Schema project on GitHub<br>
>>>> (<a href="https://github.com/highsource/ogc-schemas" target="_blank">https://github.com/highsource/ogc-schemas</a>). OGC Schemas compiles (as<br>
>>>> you<br>
>>>> guess) OGC Schemas producing JAXB schema-derived classes as well as<br>
>>>> Jsonix<br>
>>>> mappings:<br>
>>>><br>
>>>> <a href="https://github.com/highsource/ogc-schemas/tree/master/scripts" target="_blank">https://github.com/highsource/ogc-schemas/tree/master/scripts</a><br>
>>>><br>
>>>> With this project, there will be no need to compile the schemas on your<br>
>>>> own.<br>
>>>> Just take the already compiled mappings. In code it looks as follows:<br>
>>>><br>
>>>> var XLink_1_0 = require('W3C-Schemas').XLink_1_0;<br>
>>>> var OWS_1_1_0 = require('OGC-Schemas').OWS_1_1_0;<br>
>>>> var WPS_1_0_0 = require('OGC-Schemas').WPS_1_0_0;<br>
>>>><br>
>>>> var context = new Jsonix.Context([XLink_1_0, OWS_1_1_0, WPS_1_0_0]);<br>
>>>> var unmarshaller = context.createUnmarshaller();<br>
>>>> unmarshaller.unmarshalFile("tests/WPS/1.0.0/execute-01.xml",<br>
>>>> function(result) {<br>
>>>> test.equal("geom", result.value.dataInputs.input[0].title.value);<br>
>>>> test.done();<br>
>>>> });<br>
>>>><br>
>>>><br>
>>>><br>
>>>> This is code above a node.js version, will look similar in browser. Just<br>
>>>> include OGC-Schemas/OWS_1_1_0.js.<br>
>>>> RequireJS/AMD is supported out of the box.<br>
>>>><br>
>>>> See the Jsonix tests for OGC Schemas here:<br>
>>>> <a href="https://github.com/highsource/ogc-schemas/tree/master/scripts/tests" target="_blank">https://github.com/highsource/ogc-schemas/tree/master/scripts/tests</a><br>
>>>><br>
>>>> The first version (2.0.0 due to historic reasons) already published to<br>
>>>> NPM:<br>
>>>><br>
>>>> <a href="https://www.npmjs.org/package/ogc-schemas" target="_blank">https://www.npmjs.org/package/ogc-schemas</a><br>
>>>><br>
>>>> Bower registration will come in one of the next versions.<br>
>>>><br>
>>>> Last days I\ve been adding more and more schemas, here's what is<br>
>>>> currently<br>
>>>> supported:<br>
>>>><br>
>>>> * Filter_1_0_0<br>
>>>> * Filter_1_1_0<br>
>>>> * Filter_2_0<br>
>>>> * GML_2_1_2<br>
>>>> * GML_3_1_1<br>
>>>> * SMIL_2_0<br>
>>>> * SMIL_2_0_Language<br>
>>>> * OWS_1_0_0<br>
>>>> * OWS_1_1_0<br>
>>>> * OWS_2_0<br>
>>>> * WCS_1_0_0<br>
>>>> * WCS_1_1<br>
>>>> * WFS_1_0_0<br>
>>>> * WFS_1_1_0<br>
>>>> * WFS_2_0<br>
>>>> * WMS_1_0_0<br>
>>>> * WMS_1_1_0<br>
>>>> * WMS_1_1_1<br>
>>>> * WMS_1_3_0<br>
>>>> * WPS_1_0_0<br>
>>>><br>
>>>> So I think in a couple of days we'll support everything the Python<br>
>>>> OWSLib<br>
>>>> supports. I takes ca. 15-30 min to add a new schema/version.<br>
>>>><br>
>>>> I have to admit that there were a couple of problems compiling these<br>
>>>> schemas, however everything was very well resolveable. Jsonix 2.0.12 and<br>
>>>> Jsonix Schema Compiler 2.1.0 are published now (NPM, Bower, Maven<br>
>>>> Central).<br>
>>>><br>
>>>><br>
>>>> I would like to thank Bart van den Eijnden for his great help a lot with<br>
>>>> the<br>
>>>> project.<br>
>>>><br>
>>>><br>
>>>> Now I'd like to addres a few points from Éric Lemoine's mail:<br>
>>>><br>
>>>> * Jsonix creates plain JavaScript objects with almost no own types. Few<br>
>>>> exceptions are QNames and DateTime/Calendar types (both can be avoided).<br>
>>>> * Jsonix only addresses XML parsing/serializing<br>
>>>> (unmarshalling/marshalling)<br>
>>>> XML into JavaScript and vice versa. Jsonix on its own will not create<br>
>>>> instances of OL or Leaflet classes, this is not in scope. The purpose of<br>
>>>> Jsonix is to releave you from the XML parsing/serializing peculiarities<br>
>>>> so<br>
>>>> that you can concentrate on the pure JavaScript payload in a predictable<br>
>>>> form.<br>
>>>> * Jsonix works with OL2 in any case and will be able to work in OL 3.<br>
>>>> Not<br>
>>>> tested yet but I don't expect problems there. Leaflet should also be no<br>
>>>> problem. In fact, should work basically with anything since I'm<br>
>>>> extremely<br>
>>>> cautious about globals pollution and such things.<br>
>>>> * Jsonix is not yet Closure-ready but I think this is an important<br>
>>>> feature<br>
>>>> and this will be implemented. So you should be able to use a fraction of<br>
>>>> formats then.<br>
>>>><br>
>>>> Best wishes,<br>
>>>> Alexey<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> owsjs mailing list<br>
>>>> <a href="mailto:owsjs@lists.osgeo.org">owsjs@lists.osgeo.org</a><br>
>>>> <a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs</a><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Eric Lemoine<br>
>>><br>
>>> Camptocamp France SAS<br>
>>> Savoie Technolac, BP 352<br>
>>> 73377 Le Bourget du Lac, Cedex<br>
>>><br>
>>> Tel : 00 33 4 79 44 44 94<br>
>>> Mail : <a href="mailto:eric.lemoine@camptocamp.com">eric.lemoine@camptocamp.com</a><br>
>>> <a href="http://www.camptocamp.com" target="_blank">http://www.camptocamp.com</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> owsjs mailing list<br>
>> <a href="mailto:owsjs@lists.osgeo.org">owsjs@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs</a><br>
><br>
><br>
><br>
> --<br>
> Pierre GIRAUD<br>
> Géomaticien, Analyste<br>
><br>
> Camptocamp France SAS<br>
> Savoie Technolac, BP 352<br>
> 73377 Le Bourget du Lac, Cedex<br>
><br>
> Tel : 00 33 4 79 44 44 93<br>
> Mail : <a href="mailto:pierre.giraud@camptocamp.com">pierre.giraud@camptocamp.com</a><br>
> <a href="http://www.camptocamp.com" target="_blank">http://www.camptocamp.com</a><br>
</div></div></blockquote></div><br></div>