[ows.js] Update on Jsonix status and OGC Schemas

Wed Sep 3 09:02:17 PDT 2014

On Wed, Sep 3, 2014 at 5:58 PM, Aleksei Valikov
<aleksei.valikov at gmail.com> wrote:
> Hi,
>
> 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?

This would be awesome even though it would have been a good exercice
for us to resolve the compilation issues ourselves.

You can find example documents in the OpenLayers 2 tests.
https://github.com/openlayers/openlayers/blob/master/tests/Format/OWSContext/v0_3_1.html

I hope you'll be able to extract the documents from there without too much pain.

Thanks again for your help.

>
> 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.
> Finally, the libs behind Jsonix compiler also have quite a few issues. Everything is solveable but you need experience to do that.
>
> I'd gladly overtake compilation of schemas you guys need. Just tell me, which schemas.
>
> Best wishes,
> Alexey
>
>> Am 03.09.2014 um 16:44 schrieb Pierre Giraud <pierre.giraud at camptocamp.com>:
>>
>> Hello,
>>
>> I'm Pierre GIRAUD. I work with Éric at camptocamp.
>>
>>
>>
>>> On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <valikov at gmx.net> wrote:
>>> Hi Eric,
>>>
>>> the first problem is trivial:
>>>
>>> http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd
>>>
>>> does not longer exist.
>>>
>>>
>>>
>>> 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.
>>>
>>> Here's the customization I use:
>>>
>>> https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/binding.xjb
>>>
>>> It is also recommended to save the schema locally and to "redirect" the URL
>>> to that location using a catalog file:
>>>
>>> https://github.com/highsource/w3c-schemas/blob/master/xlink/1999/src/main/resources/catalog.cat
>>>
>>> So you'll finally end up with a CLI command like:
>>>
>>> java -jar jsonix-schema-compiler-full.jar -catalog catalog.cat -b
>>> bindings.xjb -extension owsContext.xsd.
>>
>> We'll give it a try unless you've already done it yourself.
>>>
>>>
>>> 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.
>>>
>>> By the way the ows schemas are already compiled:
>>>
>>> https://github.com/highsource/ogc-schemas/tree/master/ows
>>> https://github.com/highsource/ogc-schemas/tree/master/scripts/lib
>>
>> Unfortunately, OWS (common) is different from OWS Context.
>>
>>>
>>> (I'll add a test later on.)
>>>
>>> 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?
>>
>> We already know that 0.3.1 is outdated. For an unknown reason we
>> cannot find any information about it on the OGC website.
>> However we still have documents to parse using this schema. The idea
>> is to migrate an application from OpenLayers 2 (in which a OWSContext
>> Format exists) to OpenLayers 3 and keep things running correctly.
>>
>> Regards,
>> Pierre
>>
>>
>>>
>>>
>>>
>>> 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.
>>>
>>> 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.
>>> I doubt that Closure Compiler will be able to do this reasonably.
>>> 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).
>>>
>>> You can surely minify the mappings with Closure Compiler afterwards.
>>>
>>> Best wishes,
>>> Alexey
>>>
>>>
>>> On Wed, Sep 3, 2014 at 3:02 PM, Eric Lemoine <eric.lemoine at camptocamp.com>
>>> wrote:
>>>>
>>>> Hi Aleksei
>>>>
>>>> Great work on jsonix and ogc-schemas!
>>>>
>>>> At Camptocamp we've tried to use jsonix for OWSContext 0.3.1 :
>>>> <http://www.ogcnetwork.net/schemas/owc/0.3.1/owsContext.xsd>. But
>>>> we've had problems. When reading the owsContext.xsd file without any
>>>> modification, we get the following error at:
>>>>
>>>> ------------------
>>>> $ java -jar jsonix-schema-compiler-full-2.0.0.jar -d /tmp/owscontext
>>>> owsContext.xsd
>>>> [WARNING] schema_reference.4: Failed to read schema document
>>>> 'http://schemas.opengis.net/xlink/1.0.0/xlinks.xsd', because 1) could
>>>> not find the document; 2) the document could not be read; 3) the root
>>>> element of the document is not <xsd:schema>.
>>>> ------------------
>>>>
>>>> This first error seems to be related to the fact that the xlink xsd
>>>> was archived on OpenGIS. See
>>>> <http://schemas.opengis.net/xlink/ReadMe.txt>. After removing the
>>>> corresponding xs:import line from the owsContext.xsd file we get the
>>>> following new errors:
>>>>
>>>> ------------------
>>>> $ java -jar jsonix-schema-compiler-full-2.0.0.jar -d /tmp/owscontext
>>>> owsContext.xsd
>>>> [ERROR] Property "Title" is already defined. Use <jaxb:property> to
>>>> resolve this conflict.
>>>> line 232 of http://www.w3.org/1999/xlink.xsd
>>>>
>>>> [ERROR] The following location is relevant to the above error
>>>> line 219 of http://www.w3.org/1999/xlink.xsd
>>>>
>>>> [ERROR] Property "Title" is already defined. Use <jaxb:property> to
>>>> resolve this conflict.
>>>> line 261 of http://www.w3.org/1999/xlink.xsd
>>>>
>>>> [ERROR] The following location is relevant to the above error
>>>> line 246 of http://www.w3.org/1999/xlink.xsd
>>>>
>>>> Exception in thread "main" java.lang.NullPointerException
>>>> at
>>>> org.jvnet.jaxb2_commons.util.CustomizationUtils.getCustomizations(CustomizationUtils.java:475)
>>>> at
>>>> org.jvnet.jaxb2_commons.util.CustomizationUtils.findCustomizations(CustomizationUtils.java:247)
>>>> at org.hisrc.jsonix.JsonixMain.execute(JsonixMain.java:113)
>>>> at org.hisrc.jsonix.JsonixMain.main(JsonixMain.java:92)
>>>> ------------------
>>>>
>>>> Do you know why we have these errors? Would you agree to try the
>>>> owsContext.xsd file yourself? If it works the resulting js file could
>>>> possibly be added to ogc-schemas.
>>>>
>>>> Also, thanks a lot for the answers you provided to my questions. They
>>>> all make sense to me. As I said I'd be very interested to be able to
>>>> compile (with Closure Compiler) both the Jsonix library and the
>>>> ogc-schemas scripts. But I still need to investigate how feasible this
>>>> is. I hope to have a look at this.
>>>>
>>>> Thanks for lot, and thanks in advance for looking at the OWSContext.xsd
>>>> file!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Wed, Sep 3, 2014 at 9:21 AM, Aleksei Valikov <valikov at gmx.net> wrote:
>>>>> Hi,
>>>>>
>>>>> here's a short update on the Jsonix progress in the last days.
>>>>>
>>>>> We've started the OGC Schema project on GitHub
>>>>> (https://github.com/highsource/ogc-schemas). OGC Schemas compiles (as
>>>>> you
>>>>> guess) OGC Schemas producing JAXB schema-derived classes as well as
>>>>> Jsonix
>>>>> mappings:
>>>>>
>>>>> https://github.com/highsource/ogc-schemas/tree/master/scripts
>>>>>
>>>>> With this project, there will be no need to compile the schemas on your
>>>>> own.
>>>>> Just take the already compiled mappings. In code it looks as follows:
>>>>>
>>>>> var XLink_1_0 = require('W3C-Schemas').XLink_1_0;
>>>>> var OWS_1_1_0 = require('OGC-Schemas').OWS_1_1_0;
>>>>> var WPS_1_0_0 = require('OGC-Schemas').WPS_1_0_0;
>>>>>
>>>>> var context =  new Jsonix.Context([XLink_1_0, OWS_1_1_0, WPS_1_0_0]);
>>>>> var unmarshaller = context.createUnmarshaller();
>>>>> unmarshaller.unmarshalFile("tests/WPS/1.0.0/execute-01.xml",
>>>>> function(result) {
>>>>>    test.equal("geom", result.value.dataInputs.input[0].title.value);
>>>>>    test.done();
>>>>> });
>>>>>
>>>>>
>>>>>
>>>>> This is code above a node.js version, will look similar in browser. Just
>>>>> include OGC-Schemas/OWS_1_1_0.js.
>>>>> RequireJS/AMD is supported out of the box.
>>>>>
>>>>> See the Jsonix tests for OGC Schemas here:
>>>>> https://github.com/highsource/ogc-schemas/tree/master/scripts/tests
>>>>>
>>>>> The first version (2.0.0 due to historic reasons) already published to
>>>>> NPM:
>>>>>
>>>>> https://www.npmjs.org/package/ogc-schemas
>>>>>
>>>>> Bower registration will come in one of the next versions.
>>>>>
>>>>> Last days I\ve been adding more and more schemas, here's what is
>>>>> currently
>>>>> supported:
>>>>>
>>>>> * Filter_1_0_0
>>>>> * Filter_1_1_0
>>>>> * Filter_2_0
>>>>> * GML_2_1_2
>>>>> * GML_3_1_1
>>>>> * SMIL_2_0
>>>>> * SMIL_2_0_Language
>>>>> * OWS_1_0_0
>>>>> * OWS_1_1_0
>>>>> * OWS_2_0
>>>>> * WCS_1_0_0
>>>>> * WCS_1_1
>>>>> * WFS_1_0_0
>>>>> * WFS_1_1_0
>>>>> * WFS_2_0
>>>>> * WMS_1_0_0
>>>>> * WMS_1_1_0
>>>>> * WMS_1_1_1
>>>>> * WMS_1_3_0
>>>>> * WPS_1_0_0
>>>>>
>>>>> So I think in a couple of days we'll support everything the Python
>>>>> OWSLib
>>>>> supports. I takes ca. 15-30 min to add a new schema/version.
>>>>>
>>>>> I have to admit that there were a couple of problems compiling these
>>>>> schemas, however everything was very well resolveable. Jsonix 2.0.12 and
>>>>> Jsonix Schema Compiler 2.1.0 are published now (NPM, Bower, Maven
>>>>> Central).
>>>>>
>>>>>
>>>>> I would like to thank Bart van den Eijnden for his great help a lot with
>>>>> the
>>>>> project.
>>>>>
>>>>>
>>>>> Now I'd like to addres a few points from Éric Lemoine's mail:
>>>>>
>>>>> * Jsonix creates plain JavaScript objects with almost no own types. Few
>>>>> exceptions are QNames and DateTime/Calendar types (both can be avoided).
>>>>> * Jsonix only addresses XML parsing/serializing
>>>>> (unmarshalling/marshalling)
>>>>> XML into JavaScript and vice versa. Jsonix on its own will not create
>>>>> instances of OL or Leaflet classes, this is not in scope. The purpose of
>>>>> Jsonix is to releave you from the XML parsing/serializing peculiarities
>>>>> so
>>>>> that you can concentrate on the pure JavaScript payload in a predictable
>>>>> form.
>>>>> * Jsonix works with OL2 in any case and will be able to work in OL 3.
>>>>> Not
>>>>> tested yet but I don't expect problems there. Leaflet should also be no
>>>>> problem. In fact, should work basically with anything since I'm
>>>>> extremely
>>>>> cautious about globals pollution and such things.
>>>>> * Jsonix is not yet Closure-ready but I think this is an important
>>>>> feature
>>>>> and this will be implemented. So you should be able to use a fraction of
>>>>> formats then.
>>>>>
>>>>> Best wishes,
>>>>> Alexey
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> owsjs mailing list
>>>>> owsjs at lists.osgeo.org
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
>>>>
>>>>
>>>>
>>>> --
>>>> Eric Lemoine
>>>>
>>>> Camptocamp France SAS
>>>> Savoie Technolac, BP 352
>>>> 73377 Le Bourget du Lac, Cedex
>>>>
>>>> Tel : 00 33 4 79 44 44 94
>>>> Mail : eric.lemoine at camptocamp.com
>>>> http://www.camptocamp.com
>>>
>>>
>>>
>>> _______________________________________________
>>> owsjs mailing list
>>> owsjs at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
>>
>>
>>
>> --
>> Pierre GIRAUD
>> Géomaticien, Analyste
>>
>> Camptocamp France SAS
>> Savoie Technolac, BP 352
>> 73377 Le Bourget du Lac, Cedex
>>
>> Tel : 00 33 4 79 44 44 93
>> Mail : pierre.giraud at camptocamp.com
>> http://www.camptocamp.com

-- 
Pierre GIRAUD
Géomaticien, Analyste

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 93
Mail : pierre.giraud at camptocamp.com
http://www.camptocamp.com