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

Wed Sep 3 12:22:39 PDT 2014

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?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/owsjs/attachments/20140903/d9688f6d/attachment-0001.html>