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

Wed Sep 3 21:59:49 PDT 2014

Hi,

as promised, I've managed to compile this OWS Context schema:

https://github.com/highsource/ogc-schemas/tree/master/owc/0.3.1

Was indeed a bit tricky. I had to compile SLD 1.0.0, KML 2.2.0, Atom and
xAL first. :)

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.

I've customized OWS Context schema to "lax" the kml:Document reference:

<jaxb:bindings
node="xs:complexType[@name='LayerType']//xs:element[@ref='kml:Document']">
<xjc:dom/>
<wildcard:lax/>
</jaxb:bindings>

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.

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.
Here's how it look in the test:

https://github.com/highsource/ogc-schemas/blob/master/scripts/tests/OWC/0.3.1/OWC_0_3_1.js

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]);
var unmarshaller = context.createUnmarshaller();
unmarshaller.unmarshalFile("tests/OWC/0.3.1/example-owcContext.xml",
function(result) {
console.log(result.value.resourceList.layer[0].server[0].onlineResource[0].href);
test.equal("http://sigma.openplans.org:8080/geoserver/wms?SERVICE=WMS",
result.value.resourceList.layer[0].server[0].onlineResource[0].href);
test.done();
});

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.

I'll write a short manual on schema compilation later on. There was a dozen
of problems I ran into when doing this schema.

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.

Best wishes,
Alexey

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?
>
> 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/20140904/5d9785c7/attachment-0001.html>