<div dir="ltr">Hi Eric,<div><br></div><div>the first problem is trivial:</div><div><br></div><div><a href="http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd">http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd</a><br></div><div>
<br></div><div>does not longer exist.</div><div><br></div><div><br></div><div><br></div><div>The second problem is due to the fact that the xlinks schema defines some properties which map onto the same name "title". This mus be customized to avoid naming collission.</div>
<div><br></div><div>Here's the customization I use:</div><div><br></div><div><a href="https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/binding.xjb">https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/binding.xjb</a><br>
</div><div><br></div><div>It is also recommended to save the schema locally and to "redirect" the URL to that location using a catalog file:</div><div><br></div><div><a href="https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/catalog.cat">https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/catalog.cat</a><br>
</div><div><br></div><div>So you'll finally end up with a CLI command like:</div><div><br></div><div>java -jar jsonix-schema-compiler-full.jar -catalog <a href="http://catalog.cat">catalog.cat</a> -b bindings.xjb -extension owsContext.xsd.</div>
<div><br></div><div><br></div><div>But I hope you won't need to compile schema at all. My hope is that you could just reuse the standard mappings from ogc-schemas project.</div><div><br></div><div>By the way the ows schemas are already compiled:</div>
<div><br></div><div><a href="https://github.com/highsource/ogc-schemas/tree/master/ows">https://github.com/highsource/ogc-schemas/tree/master/ows</a><br></div><div><a href="https://github.com/highsource/ogc-schemas/tree/master/scripts/lib">https://github.com/highsource/ogc-schemas/tree/master/scripts/lib</a><br>
</div><div><br></div><div>(I'll add a test later on.)</div><div><br></div><div>Any reason you need the 0.3.1 version specifically? I mean, it's no big deal compiling that version but isn't it a bit outdated?<br>
</div><div><br></div><div><br></div><div><br></div><div>I'll be checking the Closure Compiler. Closure-compiling Jsonix runtime should not be a problem. We've an extended set of tests to check whether the compiled library would behave correctly.</div>
<div><br></div><div>As for closure-compiling the mapping files - I don't think that this would bring anything (apart from some minification). I don't think that Closure Compiler will be the right approach for mappings. Best results can be achieved when you know the subset of the schema you need - or a subset of the schema you don't need - and compile exactly the required subset. So you could get the tiny GML_3_1_1_Geometries instead of the huge GML_3_1_1.</div>
<div>I doubt that Closure Compiler will be able to do this reasonably.</div><div>But this can be a quite-an-easy to implement feature in Jsonix itself. You'd just list the elements and types you need (or explicitly list things you don't need) and Jsonix would generate a partial mapping. This will be a subset of the whole mapping - fully upwards compatible (you could alway replace GML_3_1_1_Geometries with the full GML_3_1_1).</div>
<div><br></div><div>You can surely minify the mappings with Closure Compiler afterwards.</div><div><br></div><div>Best wishes,</div><div>Alexey</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 3, 2014 at 3:02 PM, Eric Lemoine <span dir="ltr"><<a href="mailto:eric.lemoine@camptocamp.com" target="_blank">eric.lemoine@camptocamp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 org.jvnet.jaxb2_commons.util.CustomizationUtils.getCustomizations(CustomizationUtils.java:475)<br>
at 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 file!<br>
<div><div class="h5"><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 you<br>
> guess) OGC Schemas producing JAXB schema-derived classes as well as 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 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 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 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 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 Central).<br>
><br>
><br>
> I would like to thank Bart van den Eijnden for his great help a lot with 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 (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 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. 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 extremely<br>
> cautious about globals pollution and such things.<br>
> * Jsonix is not yet Closure-ready but I think this is an important 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>
</div></div>> _______________________________________________<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>
<span class="HOEnZb"><font color="#888888"><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>
</font></span></blockquote></div><br></div>