[ows.js] Fwd: Using Jsonix for OWS

Aleksei Valikov valikov at gmx.net
Tue Aug 26 06:07:05 PDT 2014 

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:
https://github.com/highsource/ogc-schemas

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 <tomkralidis at gmail.com> 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 <valikov at gmx.net>
>> To: owsjs at lists.osgeo.org
>> 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 <valikov at gmx.net> 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 <
>>> osgeo.mailinglist at gmail.com> 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 <osgeo.mailinglist at gmail.com>:
>>>>
>>>> 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 <bartvde at osgis.nl>:
>>>>>
>>>>> 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 <valikov at gmx.net> 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
>>>>>> owslibjs at lists.osgeo.org
>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> owslibjs mailing list
>>>>>> owslibjs at lists.osgeo.org
>>>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> owsjs mailing list
>>>> owsjs at lists.osgeo.org
>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs
>>>>
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/owsjs/attachments/20140826/6146278a/attachment-0001.html>

More information about the owsjs mailing list