Using Jsonix for OWS

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

Using Jsonix for OWS

Aleksei Valikov
Hi everyone,

I'd like to introduce my open-source JS library, Jsonix (https://github.com/highsource/jsonix) which - in my opinion suits very well for OWS needs.

Jsonix stands for "JSON interfaces for XML" and allows converting between JSON and XML in certain schema with no pain.
Here's a small code example to demonstrate what it looks like:

// First we construct a Jsonix context - a factory for unmarshaller (parser)
// and marshaller (serializer)
var context = new Jsonix.Context([PO]);

// Then we create a unmarshaller
var unmarshaller = context.createUnmarshaller();

// Unmarshal an object from the XML retrieved from the URL
unmarshaller.unmarshalURL('po.xml',
    // This callback function will be provided
    // with the result of the unmarshalling
    function (unmarshalled) {
        // Alice Smith
        console.log(unmarshalled.value.shipTo.name);
        // Baby Monitor
        console.log(unmarshalled.value.items.item[1].productName);
    });

You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/

Jsonix is schema-driven. You can basically take an XML Schema and compile it into JSON-XML mappings.
Jsonix will then be able to unmarshal XML into JSON which is very easy to process in JavaScript programs.
You can also marshal JSON into XML so you're getting the full XML<->JSON rountrip for free.

Java developers out there will defintely recognize similarities to JAXB. Jsonix is basically a JAXB analog for JavaScript.

I wrote Jsonix with OGC Schemas in mind.

So if you need a reliable, schema-driven, strongly-typed and structured XML-JSON conversion for you target OGC spec, you can take Jsonix, compile your schema and save all those gory XML-to-JSON-and-back details, just concentrate on your payload in a neat predictable JSON form.

Jsonix works in most browsers (browser protability is ~ OpenLayers).
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
Open-source (3-clause BSD), no strings attached.
Heavily tested.

I'd be very glad if you consider using Jsonix for OWS. I'd be happy to provide support and help as much as I can.

Best wishes,
Alexey Valikov

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

Re: Using Jsonix for OWS

Bart van den Eijnden (OSGIS)-2
I can safely say that working with JSONIX has been a pleasure for me up until now, with great help from Aleksei. I’ve used it for all WPS formats (GetCapabilities, DescribeProcess and Execute).

No need for re-inventing the wheel with owslib.js, at least with my 2 cents.

Best regards,
Bart

On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:

Hi everyone,

I'd like to introduce my open-source JS library, Jsonix (https://github.com/highsource/jsonix) which - in my opinion suits very well for OWS needs.

Jsonix stands for "JSON interfaces for XML" and allows converting between JSON and XML in certain schema with no pain.
Here's a small code example to demonstrate what it looks like:

// First we construct a Jsonix context - a factory for unmarshaller (parser)
// and marshaller (serializer)
var context = new Jsonix.Context([PO]);

// Then we create a unmarshaller
var unmarshaller = context.createUnmarshaller();

// Unmarshal an object from the XML retrieved from the URL
unmarshaller.unmarshalURL('po.xml',
    // This callback function will be provided
    // with the result of the unmarshalling
    function (unmarshalled) {
        // Alice Smith
        console.log(unmarshalled.value.shipTo.name);
        // Baby Monitor
        console.log(unmarshalled.value.items.item[1].productName);
    });

You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/

Jsonix is schema-driven. You can basically take an XML Schema and compile it into JSON-XML mappings.
Jsonix will then be able to unmarshal XML into JSON which is very easy to process in JavaScript programs.
You can also marshal JSON into XML so you're getting the full XML<->JSON rountrip for free.

Java developers out there will defintely recognize similarities to JAXB. Jsonix is basically a JAXB analog for JavaScript.

I wrote Jsonix with OGC Schemas in mind.

So if you need a reliable, schema-driven, strongly-typed and structured XML-JSON conversion for you target OGC spec, you can take Jsonix, compile your schema and save all those gory XML-to-JSON-and-back details, just concentrate on your payload in a neat predictable JSON form.

Jsonix works in most browsers (browser protability is ~ OpenLayers).
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
Open-source (3-clause BSD), no strings attached.
Heavily tested.

I'd be very glad if you consider using Jsonix for OWS. I'd be happy to provide support and help as much as I can.

Best wishes,
Alexey Valikov
_______________________________________________
owslibjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs


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

Re: [owslibjs] Using Jsonix for OWS

ThomasG
Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already done some tests cloning your project.
My only concern is about the possibility to not sharing the same definition for "ows_common" when for example I have to use in a same app WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-26 3:15 GMT+02:00 Thomas Gratier <[hidden email]>:
Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already done some tests cloning your project.
My only concern is about the possibility to not sharing the same definition for "ows_common" when for example I have to use in a same app WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <[hidden email]>:

I can safely say that working with JSONIX has been a pleasure for me up until now, with great help from Aleksei. I’ve used it for all WPS formats (GetCapabilities, DescribeProcess and Execute).

No need for re-inventing the wheel with owslib.js, at least with my 2 cents.

Best regards,
Bart

On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:

Hi everyone,

I'd like to introduce my open-source JS library, Jsonix (https://github.com/highsource/jsonix) which - in my opinion suits very well for OWS needs.

Jsonix stands for "JSON interfaces for XML" and allows converting between JSON and XML in certain schema with no pain.
Here's a small code example to demonstrate what it looks like:


// First we construct a Jsonix context - a factory for unmarshaller (parser)
// and marshaller (serializer)
var context = new Jsonix.Context([PO]);

// Then we create a unmarshaller
var unmarshaller = context.createUnmarshaller();

// Unmarshal an object from the XML retrieved from the URL
unmarshaller.unmarshalURL('po.xml',
    // This callback function will be provided
    // with the result of the unmarshalling
    function (unmarshalled) {
        // Alice Smith
        console.log(unmarshalled.value.shipTo.name);
        // Baby Monitor
        console.log(unmarshalled.value.items.item[1].productName);
    });

You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/

Jsonix is schema-driven. You can basically take an XML Schema and compile it into JSON-XML mappings.
Jsonix will then be able to unmarshal XML into JSON which is very easy to process in JavaScript programs.
You can also marshal JSON into XML so you're getting the full XML<->JSON rountrip for free.

Java developers out there will defintely recognize similarities to JAXB. Jsonix is basically a JAXB analog for JavaScript.

I wrote Jsonix with OGC Schemas in mind.

So if you need a reliable, schema-driven, strongly-typed and structured XML-JSON conversion for you target OGC spec, you can take Jsonix, compile your schema and save all those gory XML-to-JSON-and-back details, just concentrate on your payload in a neat predictable JSON form.

Jsonix works in most browsers (browser protability is ~ OpenLayers).
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
Open-source (3-clause BSD), no strings attached.
Heavily tested.

I'd be very glad if you consider using Jsonix for OWS. I'd be happy to provide support and help as much as I can.

Best wishes,
Alexey Valikov
_______________________________________________
owslibjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs


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




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

Re: [owslibjs] Using Jsonix for OWS

Aleksei Valikov
Hi,

use, Jsonix supports the use case and can share common parts out of the box.
The way this works is that you generate one mapping per schema. For instance, OWS.js for OWS, WMS.js for WMS ans so on. (Think one mapping per namespace.)
Then you create a context from the mappings you need.

var context = new Jsonix.Context([OWS, WPS]);

The context is basically a factory for the unmarshaller and the marshaller.
Check this code example for WPS:


Now, let's reexamine, what is shared/reused.
* The runtime (Jsonix classes) are fully reused, the runtime is not schema-specific.
* Since schemas are standard, mappings can be generated and shared as well. There's actually no need for everybode to generate the WPS mappings for instance. Once generated, they can be shared via node.js or bower.io and used by everybody.

Things are also RequireJS-capable so you can manage your dependencies very well here.

Best wishes,
Alexey


On Tue, Aug 26, 2014 at 3:20 AM, Thomas Gratier <[hidden email]> wrote:
Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already done some tests cloning your project.
My only concern is about the possibility to not sharing the same definition for "ows_common" when for example I have to use in a same app WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-26 3:15 GMT+02:00 Thomas Gratier <[hidden email]>:

Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already done some tests cloning your project.
My only concern is about the possibility to not sharing the same definition for "ows_common" when for example I have to use in a same app WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <[hidden email]>:

I can safely say that working with JSONIX has been a pleasure for me up until now, with great help from Aleksei. I’ve used it for all WPS formats (GetCapabilities, DescribeProcess and Execute).

No need for re-inventing the wheel with owslib.js, at least with my 2 cents.

Best regards,
Bart

On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:

Hi everyone,

I'd like to introduce my open-source JS library, Jsonix (https://github.com/highsource/jsonix) which - in my opinion suits very well for OWS needs.

Jsonix stands for "JSON interfaces for XML" and allows converting between JSON and XML in certain schema with no pain.
Here's a small code example to demonstrate what it looks like:


// First we construct a Jsonix context - a factory for unmarshaller (parser)
// and marshaller (serializer)
var context = new Jsonix.Context([PO]);

// Then we create a unmarshaller
var unmarshaller = context.createUnmarshaller();

// Unmarshal an object from the XML retrieved from the URL
unmarshaller.unmarshalURL('po.xml',
    // This callback function will be provided
    // with the result of the unmarshalling
    function (unmarshalled) {
        // Alice Smith
        console.log(unmarshalled.value.shipTo.name);
        // Baby Monitor
        console.log(unmarshalled.value.items.item[1].productName);
    });

You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/

Jsonix is schema-driven. You can basically take an XML Schema and compile it into JSON-XML mappings.
Jsonix will then be able to unmarshal XML into JSON which is very easy to process in JavaScript programs.
You can also marshal JSON into XML so you're getting the full XML<->JSON rountrip for free.

Java developers out there will defintely recognize similarities to JAXB. Jsonix is basically a JAXB analog for JavaScript.

I wrote Jsonix with OGC Schemas in mind.

So if you need a reliable, schema-driven, strongly-typed and structured XML-JSON conversion for you target OGC spec, you can take Jsonix, compile your schema and save all those gory XML-to-JSON-and-back details, just concentrate on your payload in a neat predictable JSON form.

Jsonix works in most browsers (browser protability is ~ OpenLayers).
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
Open-source (3-clause BSD), no strings attached.
Heavily tested.

I'd be very glad if you consider using Jsonix for OWS. I'd be happy to provide support and help as much as I can.

Best wishes,
Alexey Valikov
_______________________________________________
owslibjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs


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




_______________________________________________
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: [owslibjs] Using Jsonix for OWS

Aleksei Valikov
Hi,

an addition on Jsonix.

Jsonix only addresses unmarshalling and marshalling of XML according to mappings, possibly but not necessarily generated out of XML Schemas.
If you take a look at https://github.com/tomkralidis/csw4js/blob/master/src/csw4js.js, 90% of the code is the manual parsing of XML to get some JavaScript object structure - which would be then easier to work with.
Jsonix can save you this 90% of effort straight away.

Jsonix on its own is not a WPS or OWS or WFS or WMS processor. You still will need to write the processing you require. But Jsonix allows you to save huge effort on XML parsing and serializing.

Best wishes,
Alexey


On Tue, Aug 26, 2014 at 6:34 AM, Aleksei Valikov <[hidden email]> wrote:
Hi,

use, Jsonix supports the use case and can share common parts out of the box.
The way this works is that you generate one mapping per schema. For instance, OWS.js for OWS, WMS.js for WMS ans so on. (Think one mapping per namespace.)
Then you create a context from the mappings you need.

var context = new Jsonix.Context([OWS, WPS]);

The context is basically a factory for the unmarshaller and the marshaller.
Check this code example for WPS:


Now, let's reexamine, what is shared/reused.
* The runtime (Jsonix classes) are fully reused, the runtime is not schema-specific.
* Since schemas are standard, mappings can be generated and shared as well. There's actually no need for everybode to generate the WPS mappings for instance. Once generated, they can be shared via node.js or bower.io and used by everybody.

Things are also RequireJS-capable so you can manage your dependencies very well here.

Best wishes,
Alexey


On Tue, Aug 26, 2014 at 3:20 AM, Thomas Gratier <[hidden email]> wrote:
Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already done some tests cloning your project.
My only concern is about the possibility to not sharing the same definition for "ows_common" when for example I have to use in a same app WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-26 3:15 GMT+02:00 Thomas Gratier <[hidden email]>:

Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already done some tests cloning your project.
My only concern is about the possibility to not sharing the same definition for "ows_common" when for example I have to use in a same app WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <[hidden email]>:

I can safely say that working with JSONIX has been a pleasure for me up until now, with great help from Aleksei. I’ve used it for all WPS formats (GetCapabilities, DescribeProcess and Execute).

No need for re-inventing the wheel with owslib.js, at least with my 2 cents.

Best regards,
Bart

On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:

Hi everyone,

I'd like to introduce my open-source JS library, Jsonix (https://github.com/highsource/jsonix) which - in my opinion suits very well for OWS needs.

Jsonix stands for "JSON interfaces for XML" and allows converting between JSON and XML in certain schema with no pain.
Here's a small code example to demonstrate what it looks like:


// First we construct a Jsonix context - a factory for unmarshaller (parser)
// and marshaller (serializer)
var context = new Jsonix.Context([PO]);

// Then we create a unmarshaller
var unmarshaller = context.createUnmarshaller();

// Unmarshal an object from the XML retrieved from the URL
unmarshaller.unmarshalURL('po.xml',
    // This callback function will be provided
    // with the result of the unmarshalling
    function (unmarshalled) {
        // Alice Smith
        console.log(unmarshalled.value.shipTo.name);
        // Baby Monitor
        console.log(unmarshalled.value.items.item[1].productName);
    });

You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/

Jsonix is schema-driven. You can basically take an XML Schema and compile it into JSON-XML mappings.
Jsonix will then be able to unmarshal XML into JSON which is very easy to process in JavaScript programs.
You can also marshal JSON into XML so you're getting the full XML<->JSON rountrip for free.

Java developers out there will defintely recognize similarities to JAXB. Jsonix is basically a JAXB analog for JavaScript.

I wrote Jsonix with OGC Schemas in mind.

So if you need a reliable, schema-driven, strongly-typed and structured XML-JSON conversion for you target OGC spec, you can take Jsonix, compile your schema and save all those gory XML-to-JSON-and-back details, just concentrate on your payload in a neat predictable JSON form.

Jsonix works in most browsers (browser protability is ~ OpenLayers).
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
Open-source (3-clause BSD), no strings attached.
Heavily tested.

I'd be very glad if you consider using Jsonix for OWS. I'd be happy to provide support and help as much as I can.

Best wishes,
Alexey Valikov
_______________________________________________
owslibjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs


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




_______________________________________________
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: Using Jsonix for OWS

Tom Kralidis

Alexey: thanks for the info.  This is impressive.  Questions:

- I'm guessing leveraging JSONIX there is nothing that prevents
us from doing customized builds?
- woudc JSONIX be an ows.js runtime dependency, or a build tool as a baseline
to get all the XML Schemas into JavaScript?  Would this JavaScript then
be managed in Git or is it a build step as part of development (like managing
the actual OGC XML Schemas would be a build step to download from
http://schemas.opengis.net)? Could the added processing required following
this be done in a seperate file which leverages the JSONIX JavaScript output?
- I'm assuming browser compatability here
- does ol3, for example, leverage JSONIX for things like WFS? If not, why?

Speaking only for myself here, I think some development workflow steps
would go a long way in moving forward JSONIX adoption in ows.js.  This will
also help us start to carve out the structure of
https://github.com/OSGeo/ows.js.

On Tue, 26 Aug 2014, Aleksei Valikov wrote:

> Date: Tue, 26 Aug 2014 06:51:51 +0200
> From: Aleksei Valikov <[hidden email]>
> To: [hidden email]
> Subject: Re: [ows.js] [owslibjs] Using Jsonix for OWS
>
> Hi,
>
> an addition on Jsonix.
>
> Jsonix only addresses unmarshalling and marshalling of XML according to
> mappings, possibly but not necessarily generated out of XML Schemas.
> If you take a look at
> https://github.com/tomkralidis/csw4js/blob/master/src/csw4js.js, 90% of the
> code is the manual parsing of XML to get some JavaScript object structure -
> which would be then easier to work with.
> Jsonix can save you this 90% of effort straight away.
>
> Jsonix on its own is not a WPS or OWS or WFS or WMS processor. You still
> will need to write the processing you require. But Jsonix allows you to
> save huge effort on XML parsing and serializing.
>
> Best wishes,
> Alexey
>
>
> On Tue, Aug 26, 2014 at 6:34 AM, Aleksei Valikov <[hidden email]> wrote:
>
>> Hi,
>>
>> use, Jsonix supports the use case and can share common parts out of the
>> box.
>> The way this works is that you generate one mapping per schema. For
>> instance, OWS.js for OWS, WMS.js for WMS ans so on. (Think one mapping per
>> namespace.)
>> Then you create a context from the mappings you need.
>>
>> var context = new Jsonix.Context([OWS, WPS]);
>>
>> The context is basically a factory for the unmarshaller and the marshaller.
>> Check this code example for WPS:
>>
>>
>> https://github.com/highsource/jsonix/blob/master/nodejs/tests/wps/tests/wps-tests.js
>>
>> Now, let's reexamine, what is shared/reused.
>> * The runtime (Jsonix classes) are fully reused, the runtime is not
>> schema-specific.
>> * Since schemas are standard, mappings can be generated and shared as
>> well. There's actually no need for everybode to generate the WPS mappings
>> for instance. Once generated, they can be shared via node.js or bower.io
>> and used by everybody.
>>
>> Things are also RequireJS-capable so you can manage your dependencies very
>> well here.
>>
>> Best wishes,
>> Alexey
>>
>>
>> On Tue, Aug 26, 2014 at 3:20 AM, Thomas Gratier <
>> [hidden email]> wrote:
>>
>>> Hi,
>>>
>>> I've seen your tests in https://github.com/bartvde/ol3-wps and already
>>> done some tests cloning your project.
>>> My only concern is about the possibility to not sharing the same
>>> definition for "ows_common" when for example I have to use in a same app
>>> WPS and WMS.
>>> From my JSONIX understanding, the methods to manage each schemas are
>>> generated, does the system can share common parts?
>>> I would not like if possible to increase my overall JavaScript build size.
>>> For example, I do not want to get
>>>     ol3 + common ows for WPS + specific code for WPS + common ows for
>>> WMS + specific code for WMS
>>> but instead something like :
>>>     ol3 + common ows for WPS and WMS + specific code for WPS +  specific
>>> code for WMS
>>> Does JSONIX can already manage this use case?
>>>
>>> Regards
>>>
>>> Thomas
>>>
>>>
>>> 2014-08-26 3:15 GMT+02:00 Thomas Gratier <[hidden email]>:
>>>
>>> Hi,
>>>>
>>>> I've seen your tests in https://github.com/bartvde/ol3-wps and already
>>>> done some tests cloning your project.
>>>> My only concern is about the possibility to not sharing the same
>>>> definition for "ows_common" when for example I have to use in a same app
>>>> WPS and WMS.
>>>> From my JSONIX understanding, the methods to manage each schemas are
>>>> generated, does the system can share common parts?
>>>> I would not like if possible to increase my overall JavaScript build
>>>> size.
>>>> For example, I do not want to get
>>>>     ol3 + common ows for WPS + specific code for WPS + common ows for
>>>> WMS + specific code for WMS
>>>> but instead something like :
>>>>     ol3 + common ows for WPS and WMS + specific code for WPS +  specific
>>>> code for WMS
>>>> Does JSONIX can already manage this use case?
>>>>
>>>> Regards
>>>>
>>>> Thomas
>>>>
>>>>
>>>> 2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <[hidden email]>:
>>>>
>>>> I can safely say that working with JSONIX has been a pleasure for me up
>>>>> until now, with great help from Aleksei. I’ve used it for all WPS formats
>>>>> (GetCapabilities, DescribeProcess and Execute).
>>>>>
>>>>> No need for re-inventing the wheel with owslib.js, at least with my 2
>>>>> cents.
>>>>>
>>>>> Best regards,
>>>>> Bart
>>>>>
>>>>> On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'd like to introduce my open-source JS library, Jsonix (
>>>>> https://github.com/highsource/jsonix) which - in my opinion suits very
>>>>> well for OWS needs.
>>>>>
>>>>> Jsonix stands for "JSON interfaces for XML" and allows converting
>>>>> between JSON and XML in certain schema with no pain.
>>>>> Here's a small code example to demonstrate what it looks like:
>>>>>
>>>>> // First we construct a Jsonix context - a factory for unmarshaller (parser)// and marshaller (serializer)var context = new Jsonix.Context([PO]);
>>>>> // Then we create a unmarshallervar unmarshaller = context.createUnmarshaller();
>>>>> // Unmarshal an object from the XML retrieved from the URLunmarshaller.unmarshalURL('po.xml',
>>>>>     // This callback function will be provided
>>>>>     // with the result of the unmarshalling
>>>>>     function (unmarshalled) {
>>>>>         // Alice Smith
>>>>>         console.log(unmarshalled.value.shipTo.name);
>>>>>         // Baby Monitor
>>>>>         console.log(unmarshalled.value.items.item[1].productName);
>>>>>     });
>>>>>
>>>>>
>>>>> You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/
>>>>>
>>>>> Jsonix is schema-driven. You can basically take an XML Schema and
>>>>> compile it into JSON-XML mappings.
>>>>> Jsonix will then be able to unmarshal XML into JSON which is very easy
>>>>> to process in JavaScript programs.
>>>>> You can also marshal JSON into XML so you're getting the full
>>>>> XML<->JSON rountrip for free.
>>>>>
>>>>> Java developers out there will defintely recognize similarities to
>>>>> JAXB. Jsonix is basically a JAXB analog for JavaScript.
>>>>>
>>>>> I wrote Jsonix with OGC Schemas in mind.
>>>>> Here's a WMS demo:
>>>>> https://github.com/highsource/jsonix/tree/master/demos/wms
>>>>> Here's a sample WPS project:
>>>>> https://github.com/highsource/jsonix/tree/master/nodejs/tests/wps
>>>>>
>>>>> So if you need a reliable, schema-driven, strongly-typed and structured
>>>>> XML-JSON conversion for you target OGC spec, you can take Jsonix, compile
>>>>> your schema and save all those gory XML-to-JSON-and-back details, just
>>>>> concentrate on your payload in a neat predictable JSON form.
>>>>>
>>>>> Jsonix works in most browsers (browser protability is ~ OpenLayers).
>>>>> Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
>>>>> Open-source (3-clause BSD), no strings attached.
>>>>> Heavily tested.
>>>>>
>>>>> I'd be very glad if you consider using Jsonix for OWS. I'd be happy to
>>>>> provide support and help as much as I can.
>>>>>
>>>>> Best wishes,
>>>>> Alexey Valikov
>>>>>  _______________________________________________
>>>>> owslibjs mailing list
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> owslibjs mailing list
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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: Using Jsonix for OWS

Bart van den Eijnden (OSGIS)-2
Let me take a stab at answering your questions Tom, then Aleksei can correct me where I’m wrong or incomplete ….

On 26 Aug 2014, at 13:33, Tom Kralidis <[hidden email]> wrote:

>
> Alexey: thanks for the info.  This is impressive.  Questions:
>
> - I'm guessing leveraging JSONIX there is nothing that prevents
> us from doing customized builds?

With customising builds, you mean a build of owsjslib that only supports WMS for instance?

If so, the JSONIX runtime will be needed at all times, as well as the mapping file(s) for WMS in that case. So I don’t see any road blocks here. We can simply take the mappings that we would need.

> - woudc JSONIX be an ows.js runtime dependency, or a build tool as a baseline
> to get all the XML Schemas into JavaScript?  Would this JavaScript then
> be managed in Git or is it a build step as part of development (like managing
> the actual OGC XML Schemas would be a build step to download from
> http://schemas.opengis.net)? Could the added processing required following
> this be done in a seperate file which leverages the JSONIX JavaScript output?

If JSONIX will provide a schema repository for the mapping files, we would not need to run the command-line tools to generate the mapping files ourselves.

The JSONIX runtime would still be a dependency though for parsing / serialising, as well as the necessary mapping files.

> - I'm assuming browser compatability here

Yes browser compatibility is pretty good in JSONIX. It aims to be the same as OpenLayers 2.

> - does ol3, for example, leverage JSONIX for things like WFS? If not, why?

No it does not. Some complications here come from using the Closure Compiler (CC) in advanced mode.
I think potentially this could be done though, but JSONIX command-line would need to generate the CC typedefs as well.

Since formats such as WFS/GML are closely tied to the feature / geometry model, these might not make the most sense.
The simplest case is formats such as WMS GetCapabilities, or OWS Context, and that would be a better start than GML/WFS IMHO.

>
> Speaking only for myself here, I think some development workflow steps
> would go a long way in moving forward JSONIX adoption in ows.js.  This will
> also help us start to carve out the structure of
> https://github.com/OSGeo/ows.js.
>
> On Tue, 26 Aug 2014, Aleksei Valikov wrote:
>
>> Date: Tue, 26 Aug 2014 06:51:51 +0200
>> From: Aleksei Valikov <[hidden email]>
>> To: [hidden email]
>> Subject: Re: [ows.js] [owslibjs] Using Jsonix for OWS
>> Hi,
>>
>> an addition on Jsonix.
>>
>> Jsonix only addresses unmarshalling and marshalling of XML according to
>> mappings, possibly but not necessarily generated out of XML Schemas.
>> If you take a look at
>> https://github.com/tomkralidis/csw4js/blob/master/src/csw4js.js, 90% of the
>> code is the manual parsing of XML to get some JavaScript object structure -
>> which would be then easier to work with.
>> Jsonix can save you this 90% of effort straight away.
>>
>> Jsonix on its own is not a WPS or OWS or WFS or WMS processor. You still
>> will need to write the processing you require. But Jsonix allows you to
>> save huge effort on XML parsing and serializing.
>>
>> Best wishes,
>> Alexey
>>
>>
>> On Tue, Aug 26, 2014 at 6:34 AM, Aleksei Valikov <[hidden email]> wrote:
>>
>>> Hi,
>>>
>>> use, Jsonix supports the use case and can share common parts out of the
>>> box.
>>> The way this works is that you generate one mapping per schema. For
>>> instance, OWS.js for OWS, WMS.js for WMS ans so on. (Think one mapping per
>>> namespace.)
>>> Then you create a context from the mappings you need.
>>>
>>> var context = new Jsonix.Context([OWS, WPS]);
>>>
>>> The context is basically a factory for the unmarshaller and the marshaller.
>>> Check this code example for WPS:
>>>
>>>
>>> https://github.com/highsource/jsonix/blob/master/nodejs/tests/wps/tests/wps-tests.js
>>>
>>> Now, let's reexamine, what is shared/reused.
>>> * The runtime (Jsonix classes) are fully reused, the runtime is not
>>> schema-specific.
>>> * Since schemas are standard, mappings can be generated and shared as
>>> well. There's actually no need for everybode to generate the WPS mappings
>>> for instance. Once generated, they can be shared via node.js or bower.io
>>> and used by everybody.
>>>
>>> Things are also RequireJS-capable so you can manage your dependencies very
>>> well here.
>>>
>>> Best wishes,
>>> Alexey
>>>
>>>
>>> On Tue, Aug 26, 2014 at 3:20 AM, Thomas Gratier <
>>> [hidden email]> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've seen your tests in https://github.com/bartvde/ol3-wps and already
>>>> done some tests cloning your project.
>>>> My only concern is about the possibility to not sharing the same
>>>> definition for "ows_common" when for example I have to use in a same app
>>>> WPS and WMS.
>>>> From my JSONIX understanding, the methods to manage each schemas are
>>>> generated, does the system can share common parts?
>>>> I would not like if possible to increase my overall JavaScript build size.
>>>> For example, I do not want to get
>>>>    ol3 + common ows for WPS + specific code for WPS + common ows for
>>>> WMS + specific code for WMS
>>>> but instead something like :
>>>>    ol3 + common ows for WPS and WMS + specific code for WPS +  specific
>>>> code for WMS
>>>> Does JSONIX can already manage this use case?
>>>>
>>>> Regards
>>>>
>>>> Thomas
>>>>
>>>>
>>>> 2014-08-26 3:15 GMT+02:00 Thomas Gratier <[hidden email]>:
>>>>
>>>> Hi,
>>>>>
>>>>> I've seen your tests in https://github.com/bartvde/ol3-wps and already
>>>>> done some tests cloning your project.
>>>>> My only concern is about the possibility to not sharing the same
>>>>> definition for "ows_common" when for example I have to use in a same app
>>>>> WPS and WMS.
>>>>> From my JSONIX understanding, the methods to manage each schemas are
>>>>> generated, does the system can share common parts?
>>>>> I would not like if possible to increase my overall JavaScript build
>>>>> size.
>>>>> For example, I do not want to get
>>>>>    ol3 + common ows for WPS + specific code for WPS + common ows for
>>>>> WMS + specific code for WMS
>>>>> but instead something like :
>>>>>    ol3 + common ows for WPS and WMS + specific code for WPS +  specific
>>>>> code for WMS
>>>>> Does JSONIX can already manage this use case?
>>>>>
>>>>> Regards
>>>>>
>>>>> Thomas
>>>>>
>>>>>
>>>>> 2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <[hidden email]>:
>>>>>
>>>>> I can safely say that working with JSONIX has been a pleasure for me up
>>>>>> until now, with great help from Aleksei. I’ve used it for all WPS formats
>>>>>> (GetCapabilities, DescribeProcess and Execute).
>>>>>>
>>>>>> No need for re-inventing the wheel with owslib.js, at least with my 2
>>>>>> cents.
>>>>>>
>>>>>> Best regards,
>>>>>> Bart
>>>>>>
>>>>>> On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I'd like to introduce my open-source JS library, Jsonix (
>>>>>> https://github.com/highsource/jsonix) which - in my opinion suits very
>>>>>> well for OWS needs.
>>>>>>
>>>>>> Jsonix stands for "JSON interfaces for XML" and allows converting
>>>>>> between JSON and XML in certain schema with no pain.
>>>>>> Here's a small code example to demonstrate what it looks like:
>>>>>>
>>>>>> // First we construct a Jsonix context - a factory for unmarshaller (parser)// and marshaller (serializer)var context = new Jsonix.Context([PO]);
>>>>>> // Then we create a unmarshallervar unmarshaller = context.createUnmarshaller();
>>>>>> // Unmarshal an object from the XML retrieved from the URLunmarshaller.unmarshalURL('po.xml',
>>>>>>    // This callback function will be provided
>>>>>>    // with the result of the unmarshalling
>>>>>>    function (unmarshalled) {
>>>>>>        // Alice Smith
>>>>>>        console.log(unmarshalled.value.shipTo.name);
>>>>>>        // Baby Monitor
>>>>>>        console.log(unmarshalled.value.items.item[1].productName);
>>>>>>    });
>>>>>>
>>>>>>
>>>>>> You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/
>>>>>>
>>>>>> Jsonix is schema-driven. You can basically take an XML Schema and
>>>>>> compile it into JSON-XML mappings.
>>>>>> Jsonix will then be able to unmarshal XML into JSON which is very easy
>>>>>> to process in JavaScript programs.
>>>>>> You can also marshal JSON into XML so you're getting the full
>>>>>> XML<->JSON rountrip for free.
>>>>>>
>>>>>> Java developers out there will defintely recognize similarities to
>>>>>> JAXB. Jsonix is basically a JAXB analog for JavaScript.
>>>>>>
>>>>>> I wrote Jsonix with OGC Schemas in mind.
>>>>>> Here's a WMS demo:
>>>>>> https://github.com/highsource/jsonix/tree/master/demos/wms
>>>>>> Here's a sample WPS project:
>>>>>> https://github.com/highsource/jsonix/tree/master/nodejs/tests/wps
>>>>>>
>>>>>> So if you need a reliable, schema-driven, strongly-typed and structured
>>>>>> XML-JSON conversion for you target OGC spec, you can take Jsonix, compile
>>>>>> your schema and save all those gory XML-to-JSON-and-back details, just
>>>>>> concentrate on your payload in a neat predictable JSON form.
>>>>>>
>>>>>> Jsonix works in most browsers (browser protability is ~ OpenLayers).
>>>>>> Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
>>>>>> Open-source (3-clause BSD), no strings attached.
>>>>>> Heavily tested.
>>>>>>
>>>>>> I'd be very glad if you consider using Jsonix for OWS. I'd be happy to
>>>>>> provide support and help as much as I can.
>>>>>>
>>>>>> Best wishes,
>>>>>> Alexey Valikov
>>>>>> _______________________________________________
>>>>>> owslibjs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> owslibjs mailing list
>>>>>> [hidden email]
>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Fwd: Using Jsonix for OWS

Aleksei Valikov
In reply to this post by Tom Kralidis
Hi,

> - I'm guessing leveraging JSONIX there is nothing that prevents us from doing customized builds?

Not quite sure what you mean by customized builds. But generally you configure Jsonix with mappings (also JS). Here's how I can imagine customzation here:
* One option is to choose which schemas and versions you need in your application. Like, [OWS_V_1_0_0, WMS_V_1_3_0] is one case, [OWS_V_1_0_0, GML_V_3_1_1, WFS_V_1_1_0] in the other.
* Another option is that you may not need the whole GML_V_3_1_1 for instance. You can then compile a subset of GML 3.1.1 which you need for your case.

> - woudc JSONIX be an ows.js runtime dependency, or a build tool as a baseline
to get all the XML Schemas into JavaScript?

Jsonix itself would be a runtime dependency. 

As for the build tool - I think the best option would be to compile OGC Schemas and provide the generated mappings in a separate project.
I've already started it:

So as long as individual projects/apps use standard mappings they won't need Jsonix as a build tool. Only if the project wants to do someting non-standard.

> Would this JavaScript then
be managed in Git or is it a build step as part of development (like managing
the actual OGC XML Schemas would be a build step to download from
http://schemas.opengis.net)? tricky

See above. :)
ogc-schemas project on GitHub will compile OGC Schemas with the Jsonix schema compiler and distribute the generated standard mappings via npm, bower.io or whatever else out there. Projects could then use the generated mappings directly.

Alternatively, if a project needs something proprietary, it can compile schemas on its own. ogc-schemas project would then help by providing sample bindings/build files.

>Could the added processing required following
this be done in a seperate file which leverages the JSONIX JavaScript output?

Sorry, I did not understood the question...

> - I'm assuming browser compatability here

Yep. ~OL2.
node.js is supported as well

> - does ol3, for example, leverage JSONIX for things like WFS? If not, why?

Not at the moment. I'm not sure why, my guess would be - Jsonix is a relatively new kid on the block. OL XML formats are much older, wouldn't make much sense to rewrite them.

See also the comment from Bart. Jsonix does not support the Closure Compiler _at the moment_, but I guess this is surely doable.

Taking WFS specifically, I'm not quite sure if this is a good match for Jsonix. Since you normally have GML Feature Profiles there - which you may need to compile extra to make the whole thing work.
I'll have to experiment a bit more here.
Things like GetCapabilities etc. are generally no problem.

Best wishes,
Alexey


On Tue, Aug 26, 2014 at 1:33 PM, Tom Kralidis <[hidden email]> wrote:

Alexey: thanks for the info.  This is impressive.  Questions:

- I'm guessing leveraging JSONIX there is nothing that prevents
us from doing customized builds?
- woudc JSONIX be an ows.js runtime dependency, or a build tool as a baseline
to get all the XML Schemas into JavaScript?  Would this JavaScript then
be managed in Git or is it a build step as part of development (like managing
the actual OGC XML Schemas would be a build step to download from
http://schemas.opengis.net)? Could the added processing required following
this be done in a seperate file which leverages the JSONIX JavaScript output?
- I'm assuming browser compatability here
- does ol3, for example, leverage JSONIX for things like WFS? If not, why?

Speaking only for myself here, I think some development workflow steps
would go a long way in moving forward JSONIX adoption in ows.js.  This will
also help us start to carve out the structure of
https://github.com/OSGeo/ows.js.

On Tue, 26 Aug 2014, Aleksei Valikov wrote:

Date: Tue, 26 Aug 2014 06:51:51 +0200
From: Aleksei Valikov <[hidden email]>
To: [hidden email]
Subject: Re: [ows.js] [owslibjs] Using Jsonix for OWS


Hi,

an addition on Jsonix.

Jsonix only addresses unmarshalling and marshalling of XML according to
mappings, possibly but not necessarily generated out of XML Schemas.
If you take a look at
https://github.com/tomkralidis/csw4js/blob/master/src/csw4js.js, 90% of the
code is the manual parsing of XML to get some JavaScript object structure -
which would be then easier to work with.
Jsonix can save you this 90% of effort straight away.

Jsonix on its own is not a WPS or OWS or WFS or WMS processor. You still
will need to write the processing you require. But Jsonix allows you to
save huge effort on XML parsing and serializing.

Best wishes,
Alexey


On Tue, Aug 26, 2014 at 6:34 AM, Aleksei Valikov <[hidden email]> wrote:

Hi,

use, Jsonix supports the use case and can share common parts out of the
box.
The way this works is that you generate one mapping per schema. For
instance, OWS.js for OWS, WMS.js for WMS ans so on. (Think one mapping per
namespace.)
Then you create a context from the mappings you need.

var context = new Jsonix.Context([OWS, WPS]);

The context is basically a factory for the unmarshaller and the marshaller.
Check this code example for WPS:


https://github.com/highsource/jsonix/blob/master/nodejs/tests/wps/tests/wps-tests.js

Now, let's reexamine, what is shared/reused.
* The runtime (Jsonix classes) are fully reused, the runtime is not
schema-specific.
* Since schemas are standard, mappings can be generated and shared as
well. There's actually no need for everybode to generate the WPS mappings
for instance. Once generated, they can be shared via node.js or bower.io
and used by everybody.

Things are also RequireJS-capable so you can manage your dependencies very
well here.

Best wishes,
Alexey


On Tue, Aug 26, 2014 at 3:20 AM, Thomas Gratier <
[hidden email]> wrote:

Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already
done some tests cloning your project.
My only concern is about the possibility to not sharing the same
definition for "ows_common" when for example I have to use in a same app
WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are
generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for
WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific
code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-26 3:15 GMT+02:00 Thomas Gratier <[hidden email]>:

Hi,

I've seen your tests in https://github.com/bartvde/ol3-wps and already
done some tests cloning your project.
My only concern is about the possibility to not sharing the same
definition for "ows_common" when for example I have to use in a same app
WPS and WMS.
From my JSONIX understanding, the methods to manage each schemas are
generated, does the system can share common parts?
I would not like if possible to increase my overall JavaScript build
size.
For example, I do not want to get
    ol3 + common ows for WPS + specific code for WPS + common ows for
WMS + specific code for WMS
but instead something like :
    ol3 + common ows for WPS and WMS + specific code for WPS +  specific
code for WMS
Does JSONIX can already manage this use case?

Regards

Thomas


2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <[hidden email]>:

I can safely say that working with JSONIX has been a pleasure for me up
until now, with great help from Aleksei. I’ve used it for all WPS formats
(GetCapabilities, DescribeProcess and Execute).

No need for re-inventing the wheel with owslib.js, at least with my 2
cents.

Best regards,
Bart

On 17 Aug 2014, at 20:30, Aleksei Valikov <[hidden email]> wrote:

Hi everyone,

I'd like to introduce my open-source JS library, Jsonix (
https://github.com/highsource/jsonix) which - in my opinion suits very
well for OWS needs.

Jsonix stands for "JSON interfaces for XML" and allows converting
between JSON and XML in certain schema with no pain.
Here's a small code example to demonstrate what it looks like:

// First we construct a Jsonix context - a factory for unmarshaller (parser)// and marshaller (serializer)var context = new Jsonix.Context([PO]);
// Then we create a unmarshallervar unmarshaller = context.createUnmarshaller();
// Unmarshal an object from the XML retrieved from the URLunmarshaller.unmarshalURL('po.xml',

    // This callback function will be provided
    // with the result of the unmarshalling
    function (unmarshalled) {
        // Alice Smith
        console.log(unmarshalled.value.shipTo.name);
        // Baby Monitor
        console.log(unmarshalled.value.items.item[1].productName);
    });


You can try it online in JSFiddle: http://jsfiddle.net/lexi/LP3DC/

Jsonix is schema-driven. You can basically take an XML Schema and
compile it into JSON-XML mappings.
Jsonix will then be able to unmarshal XML into JSON which is very easy
to process in JavaScript programs.
You can also marshal JSON into XML so you're getting the full
XML<->JSON rountrip for free.

Java developers out there will defintely recognize similarities to
JAXB. Jsonix is basically a JAXB analog for JavaScript.

I wrote Jsonix with OGC Schemas in mind.
Here's a WMS demo:
https://github.com/highsource/jsonix/tree/master/demos/wms
Here's a sample WPS project:
https://github.com/highsource/jsonix/tree/master/nodejs/tests/wps

So if you need a reliable, schema-driven, strongly-typed and structured
XML-JSON conversion for you target OGC spec, you can take Jsonix, compile
your schema and save all those gory XML-to-JSON-and-back details, just
concentrate on your payload in a neat predictable JSON form.

Jsonix works in most browsers (browser protability is ~ OpenLayers).
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.
Open-source (3-clause BSD), no strings attached.
Heavily tested.

I'd be very glad if you consider using Jsonix for OWS. I'd be happy to
provide support and help as much as I can.

Best wishes,
Alexey Valikov
 _______________________________________________
owslibjs mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs



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




_______________________________________________
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