Update on Jsonix status and OGC Schemas

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Update on Jsonix status and OGC Schemas

Aleksei Valikov
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:


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.


The first version (2.0.0 due to historic reasons) already published to NPM:


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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Update on Jsonix status and OGC Schemas

erilem
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 &lt;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 &lt;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 <[hidden email]> 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
> [hidden email]
> 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 : [hidden email]
http://www.camptocamp.com
_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Update on Jsonix status and OGC Schemas

Aleksei Valikov
Hi Eric,

the first problem is trivial:


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:


It is also recommended to save the schema locally and to "redirect" the URL to that location using a catalog file:


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.


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:


(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?



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 <[hidden email]> 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 &lt;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 &lt;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 <[hidden email]> 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
> [hidden email]
> 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 : [hidden email]
http://www.camptocamp.com


_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Update on Jsonix status and OGC Schemas

Pierre Giraud-2
Hello,

I'm Pierre GIRAUD. I work with Éric at camptocamp.



On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <[hidden email]> 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 <[hidden email]>
> 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 &lt;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 &lt;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 <[hidden email]> 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
>> > [hidden email]
>> > 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 : [hidden email]
>> http://www.camptocamp.com
>
>
>
> _______________________________________________
> owsjs mailing list
> [hidden email]
> 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 : [hidden email]
http://www.camptocamp.com
_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Update on Jsonix status and OGC Schemas

Bart van den Eijnden (OSGIS)-2
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 <[hidden email]> wrote:

> Hello,
>
> I'm Pierre GIRAUD. I work with Éric at camptocamp.
>
>
>
> On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <[hidden email]> 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 <[hidden email]>
>> 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 &lt;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 &lt;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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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 : [hidden email]
>>> http://www.camptocamp.com
>>
>>
>>
>> _______________________________________________
>> owsjs mailing list
>> [hidden email]
>> 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 : [hidden email]
> http://www.camptocamp.com
> _______________________________________________
> owsjs mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs

_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Update on Jsonix status and OGC Schemas

Pierre Giraud-2
In reply to this post by Pierre Giraud-2
On Wed, Sep 3, 2014 at 5:58 PM, Aleksei Valikov
<[hidden email]> 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 <[hidden email]>:
>>
>> Hello,
>>
>> I'm Pierre GIRAUD. I work with Éric at camptocamp.
>>
>>
>>
>>> On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <[hidden email]> 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 <[hidden email]>
>>> 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 &lt;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 &lt;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 <[hidden email]> 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
>>>>> [hidden email]
>>>>> 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 : [hidden email]
>>>> http://www.camptocamp.com
>>>
>>>
>>>
>>> _______________________________________________
>>> owsjs mailing list
>>> [hidden email]
>>> 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 : [hidden email]
>> 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 : [hidden email]
http://www.camptocamp.com
_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Fwd: Update on Jsonix status and OGC Schemas

Aleksei Valikov
In reply to this post by Pierre Giraud-2
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 <[hidden email]>:
>
> Hello,
>
> I'm Pierre GIRAUD. I work with Éric at camptocamp.
>
>
>
>> On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <[hidden email]> 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 <[hidden email]>
>> 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 &lt;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 &lt;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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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 : [hidden email]
>>> http://www.camptocamp.com
>>
>>
>>
>> _______________________________________________
>> owsjs mailing list
>> [hidden email]
>> 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 : [hidden email]
> http://www.camptocamp.com


_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Update on Jsonix status and OGC Schemas

Aleksei Valikov
In reply to this post by Pierre Giraud-2
Hi,

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


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:


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 <[hidden email]> 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 <[hidden email]>:
>
> Hello,
>
> I'm Pierre GIRAUD. I work with Éric at camptocamp.
>
>
>
>> On Wed, Sep 3, 2014 at 4:09 PM, Aleksei Valikov <[hidden email]> 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 <[hidden email]>
>> 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 &lt;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 &lt;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 <[hidden email]> 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
>>>> [hidden email]
>>>> 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 : [hidden email]
>>> http://www.camptocamp.com
>>
>>
>>
>> _______________________________________________
>> owsjs mailing list
>> [hidden email]
>> 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 : [hidden email]
> http://www.camptocamp.com


_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Update on Jsonix status and OGC Schemas

nuest
In reply to this post by Aleksei Valikov
Am 03/09/2014 um 21:22 schrieb Aleksei Valikov:
> I'd gladly overtake compilation of schemas you guys need. Just tell me,
> which schemas.

Thanks for this great offer! From my point of view it would be great if
you could have a go at the sensor web schemas: SOS, O&M, SPS, SensorML.
Though with a lower priority because I won't be able to test them soon.

It would certainly be great if you collect the tricks and things you
have to do to get schemas to compile somewhere online so that eventually
somebody else can take some work off your shoulders.


Best regards,
Daniel

--
Daniel Nüst
52°North Initiative for Geospatial Open Source Software GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
E-Mail: [hidden email]
Fon: +49-(0)-251–396371-36
Fax: +49-(0)-251–396371-11

http://52north.org/
Twitter: @FiveTwoN

General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk
Local Court Muenster HRB 10849
_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Update on Jsonix status and OGC Schemas

Aleksei Valikov
Hi,

I definitely plan to make a tutorial on usual caveats.

Please let me know which versions you need. The best would be:


An issue per schema/version. Also the best to track the progress

Best wishes,
Alexey


On Thu, Sep 4, 2014 at 10:09 AM, Daniel Nüst <[hidden email]> wrote:
Am 03/09/2014 um 21:22 schrieb Aleksei Valikov:

I'd gladly overtake compilation of schemas you guys need. Just tell me,
which schemas.

Thanks for this great offer! From my point of view it would be great if you could have a go at the sensor web schemas: SOS, O&M, SPS, SensorML. Though with a lower priority because I won't be able to test them soon.

It would certainly be great if you collect the tricks and things you have to do to get schemas to compile somewhere online so that eventually somebody else can take some work off your shoulders.


Best regards,
Daniel

--
Daniel Nüst
52°North Initiative for Geospatial Open Source Software GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
E-Mail: [hidden email]
Fon: <a href="tel:%2B49-%280%29-251%E2%80%93396371-36" value="+4925139637136" target="_blank">+49-(0)-251–396371-36
Fax: <a href="tel:%2B49-%280%29-251%E2%80%93396371-11" value="+4925139637111" target="_blank">+49-(0)-251–396371-11

http://52north.org/
Twitter: @FiveTwoN

General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk
Local Court Muenster HRB 10849

_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs


_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: Update on Jsonix status and OGC Schemas

Tom Kralidis
Can we add CSW 2.0.2 as well?

Sent from my iPhone

On Sep 4, 2014, at 4:14, Aleksei Valikov <[hidden email]> wrote:

Hi,

I definitely plan to make a tutorial on usual caveats.

Please let me know which versions you need. The best would be:


An issue per schema/version. Also the best to track the progress

Best wishes,
Alexey


On Thu, Sep 4, 2014 at 10:09 AM, Daniel Nüst <[hidden email]> wrote:
Am 03/09/2014 um 21:22 schrieb Aleksei Valikov:

I'd gladly overtake compilation of schemas you guys need. Just tell me,
which schemas.

Thanks for this great offer! From my point of view it would be great if you could have a go at the sensor web schemas: SOS, O&M, SPS, SensorML. Though with a lower priority because I won't be able to test them soon.

It would certainly be great if you collect the tricks and things you have to do to get schemas to compile somewhere online so that eventually somebody else can take some work off your shoulders.


Best regards,
Daniel

--
Daniel Nüst
52°North Initiative for Geospatial Open Source Software GmbH
Martin-Luther-King-Weg 24
48155 Münster, Germany
E-Mail: [hidden email]
Fon: <a href="tel:%2B49-%280%29-251%E2%80%93396371-36" value="+4925139637136" target="_blank">+49-(0)-251–396371-36
Fax: <a href="tel:%2B49-%280%29-251%E2%80%93396371-11" value="+4925139637111" target="_blank">+49-(0)-251–396371-11

http://52north.org/
Twitter: @FiveTwoN

General Managers: Dr. Albert Remke, Dr. Andreas Wytzisk
Local Court Muenster HRB 10849

_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs

_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs

_______________________________________________
owsjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs