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

Bart van den Eijnden bartvde at osgis.nl
Wed Sep 3 07:53:13 PDT 2014 

Right, here is more info on the standard:

http://www.opengeospatial.org/standards/owc

The 0.3.1 schema is not in the official OGC schema repository, but can only be found here (the same link as Eric provided earlier):

http://www.ogcnetwork.net/schemas/owc/0.3.1/owsContext.xsd

It does import a *lot* of other OGC standards though, such as GML 2.1.2, Filter 1.0.0, SLD 1.0.0 and KML 2.2.

Best regards,
Bart

On 03 Sep 2014, at 16:44, Pierre Giraud <pierre.giraud at camptocamp.com> wrote:

> 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
> _______________________________________________
> owsjs mailing list
> owsjs at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs

More information about the owsjs mailing list