<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi,<div class=""><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> - I'm guessing leveraging JSONIX there is nothing that prevents </span><span style="font-family:arial,sans-serif;font-size:13px">us from doing customized builds?</span></div>
<div><br></div></div><div>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:</div><div>* 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.</div>
<div>* 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.</div><div class=""><div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> - woudc JSONIX be an ows.js runtime dependency, or a build tool as a baseline</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-family:arial,sans-serif;font-size:13px">to get all the XML Schemas into JavaScript?</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div></div><div><span style="font-family:arial,sans-serif;font-size:13px">Jsonix itself would be a runtime dependency. </span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div>I've already started it:</div><div><a href="https://github.com/highsource/ogc-schemas" target="_blank">https://github.com/highsource/ogc-schemas</a><br></div><div><br></div><div>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.</div>
<div><br></div><div><div class=""><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">Would this JavaScript then</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">> </span><span style="font-family:arial,sans-serif;font-size:13px">be managed in Git or is it a build step as part of development (like managing</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">the actual OGC XML Schemas would be a build step to download from</span><br style="font-family:arial,sans-serif;font-size:13px"></div><a href="http://schemas.opengis.net/" style="font-family:arial,sans-serif;font-size:13px" target="_blank">http://schemas.opengis.net</a><span style="font-family:arial,sans-serif;font-size:13px">)? tricky</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">See above. :)</span></div><div><font face="arial, sans-serif">ogc-schemas project on GitHub will compile OGC Schemas with the Jsonix schema compiler and distribute the generated standard mappings via npm, <a href="http://bower.io" target="_blank">bower.io</a> or whatever else out there. Projects could then use the generated mappings directly.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">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.</font></div>
<div class="">
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">>Could the added processing required following</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">this be done in a seperate file which leverages the JSONIX JavaScript output?</span></div>
<div><br></div></div><div>Sorry, I did not understood the question...</div><div class=""><div><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> - I'm assuming browser compatability here</span></div>
<div><br></div></div><div>Yep. ~OL2.</div><div>node.js is supported as well</div><div class=""><div><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">> - does ol3, for example, leverage JSONIX for things like WFS? If not, why?</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div><div><font face="arial, sans-serif">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.</font></div>
<div><br></div><div><font face="arial, sans-serif">See also the comment from Bart. Jsonix does not support the Closure Compiler _at the moment_, but I guess this is surely doable.</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif">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.</font></div>
<div>I'll have to experiment a bit more here.<br></div><div>Things like GetCapabilities etc. are generally no problem.</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Best wishes,</span></div>
<div>Alexey</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 1:33 PM, Tom Kralidis <span dir="ltr"><<a href="mailto:tomkralidis@gmail.com" target="_blank">tomkralidis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Alexey: thanks for the info. This is impressive. Questions:<br>
<br>
- I'm guessing leveraging JSONIX there is nothing that prevents<br>
us from doing customized builds?<br>
- woudc JSONIX be an ows.js runtime dependency, or a build tool as a baseline<br>
to get all the XML Schemas into JavaScript? Would this JavaScript then<br>
be managed in Git or is it a build step as part of development (like managing<br>
the actual OGC XML Schemas would be a build step to download from<br>
<a href="http://schemas.opengis.net" target="_blank">http://schemas.opengis.net</a>)? Could the added processing required following<br>
this be done in a seperate file which leverages the JSONIX JavaScript output?<br>
- I'm assuming browser compatability here<br>
- does ol3, for example, leverage JSONIX for things like WFS? If not, why?<br>
<br>
Speaking only for myself here, I think some development workflow steps<br>
would go a long way in moving forward JSONIX adoption in ows.js. This will<br>
also help us start to carve out the structure of<br>
<a href="https://github.com/OSGeo/ows.js" target="_blank">https://github.com/OSGeo/ows.<u></u>js</a>.<br>
<br>
On Tue, 26 Aug 2014, Aleksei Valikov wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Tue, 26 Aug 2014 06:51:51 +0200<br>
From: Aleksei Valikov <<a href="mailto:valikov@gmx.net" target="_blank">valikov@gmx.net</a>><br>
To: <a href="mailto:owsjs@lists.osgeo.org" target="_blank">owsjs@lists.osgeo.org</a><br>
Subject: Re: [ows.js] [owslibjs] Using Jsonix for OWS<div><div><br>
<br>
Hi,<br>
<br>
an addition on Jsonix.<br>
<br>
Jsonix only addresses unmarshalling and marshalling of XML according to<br>
mappings, possibly but not necessarily generated out of XML Schemas.<br>
If you take a look at<br>
<a href="https://github.com/tomkralidis/csw4js/blob/master/src/csw4js.js" target="_blank">https://github.com/<u></u>tomkralidis/csw4js/blob/<u></u>master/src/csw4js.js</a>, 90% of the<br>
code is the manual parsing of XML to get some JavaScript object structure -<br>
which would be then easier to work with.<br>
Jsonix can save you this 90% of effort straight away.<br>
<br>
Jsonix on its own is not a WPS or OWS or WFS or WMS processor. You still<br>
will need to write the processing you require. But Jsonix allows you to<br>
save huge effort on XML parsing and serializing.<br>
<br>
Best wishes,<br>
Alexey<br>
<br>
<br>
On Tue, Aug 26, 2014 at 6:34 AM, Aleksei Valikov <<a href="mailto:valikov@gmx.net" target="_blank">valikov@gmx.net</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
Hi,<br>
<br>
use, Jsonix supports the use case and can share common parts out of the<br>
box.<br>
The way this works is that you generate one mapping per schema. For<br>
instance, OWS.js for OWS, WMS.js for WMS ans so on. (Think one mapping per<br>
namespace.)<br>
Then you create a context from the mappings you need.<br>
<br>
var context = new Jsonix.Context([OWS, WPS]);<br>
<br>
The context is basically a factory for the unmarshaller and the marshaller.<br>
Check this code example for WPS:<br>
<br>
<br>
<a href="https://github.com/highsource/jsonix/blob/master/nodejs/tests/wps/tests/wps-tests.js" target="_blank">https://github.com/highsource/<u></u>jsonix/blob/master/nodejs/<u></u>tests/wps/tests/wps-tests.js</a><br>
<br>
Now, let's reexamine, what is shared/reused.<br>
* The runtime (Jsonix classes) are fully reused, the runtime is not<br>
schema-specific.<br>
* Since schemas are standard, mappings can be generated and shared as<br>
well. There's actually no need for everybode to generate the WPS mappings<br>
for instance. Once generated, they can be shared via node.js or <a href="http://bower.io" target="_blank">bower.io</a><br>
and used by everybody.<br>
<br>
Things are also RequireJS-capable so you can manage your dependencies very<br>
well here.<br>
<br>
Best wishes,<br>
Alexey<br>
<br>
<br>
On Tue, Aug 26, 2014 at 3:20 AM, Thomas Gratier <<br>
<a href="mailto:osgeo.mailinglist@gmail.com" target="_blank">osgeo.mailinglist@gmail.com</a>> wrote:<br>
<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
Hi,<br>
<br>
I've seen your tests in <a href="https://github.com/bartvde/ol3-wps" target="_blank">https://github.com/bartvde/<u></u>ol3-wps</a> and already<br>
done some tests cloning your project.<br>
My only concern is about the possibility to not sharing the same<br>
definition for "ows_common" when for example I have to use in a same app<br>
WPS and WMS.<br>
>From my JSONIX understanding, the methods to manage each schemas are<br>
generated, does the system can share common parts?<br>
I would not like if possible to increase my overall JavaScript build size.<br>
For example, I do not want to get<br>
ol3 + common ows for WPS + specific code for WPS + common ows for<br>
WMS + specific code for WMS<br>
but instead something like :<br>
ol3 + common ows for WPS and WMS + specific code for WPS + specific<br>
code for WMS<br>
Does JSONIX can already manage this use case?<br>
<br>
Regards<br>
<br>
Thomas<br>
<br>
<br>
2014-08-26 3:15 GMT+02:00 Thomas Gratier <<a href="mailto:osgeo.mailinglist@gmail.com" target="_blank">osgeo.mailinglist@gmail.com</a>>:<br>
<br>
Hi,<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<br>
I've seen your tests in <a href="https://github.com/bartvde/ol3-wps" target="_blank">https://github.com/bartvde/<u></u>ol3-wps</a> and already<br>
done some tests cloning your project.<br>
My only concern is about the possibility to not sharing the same<br>
definition for "ows_common" when for example I have to use in a same app<br>
WPS and WMS.<br>
>From my JSONIX understanding, the methods to manage each schemas are<br>
generated, does the system can share common parts?<br>
I would not like if possible to increase my overall JavaScript build<br>
size.<br>
For example, I do not want to get<br>
ol3 + common ows for WPS + specific code for WPS + common ows for<br>
WMS + specific code for WMS<br>
but instead something like :<br>
ol3 + common ows for WPS and WMS + specific code for WPS + specific<br>
code for WMS<br>
Does JSONIX can already manage this use case?<br>
<br>
Regards<br>
<br>
Thomas<br>
<br>
<br>
2014-08-20 21:17 GMT+02:00 Bart van den Eijnden <<a href="mailto:bartvde@osgis.nl" target="_blank">bartvde@osgis.nl</a>>:<br>
<br>
I can safely say that working with JSONIX has been a pleasure for me up<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
until now, with great help from Aleksei. I’ve used it for all WPS formats<br>
(GetCapabilities, DescribeProcess and Execute).<br>
<br>
No need for re-inventing the wheel with owslib.js, at least with my 2<br>
cents.<br>
<br>
Best regards,<br>
Bart<br>
<br>
On 17 Aug 2014, at 20:30, Aleksei Valikov <<a href="mailto:valikov@gmx.net" target="_blank">valikov@gmx.net</a>> wrote:<br>
<br>
Hi everyone,<br>
<br>
I'd like to introduce my open-source JS library, Jsonix (<br>
<a href="https://github.com/highsource/jsonix" target="_blank">https://github.com/highsource/<u></u>jsonix</a>) which - in my opinion suits very<br>
well for OWS needs.<br>
<br>
Jsonix stands for "JSON interfaces for XML" and allows converting<br>
between JSON and XML in certain schema with no pain.<br>
Here's a small code example to demonstrate what it looks like:<br>
<br></div></div>
// First we construct a Jsonix context - a factory for unmarshaller (parser)// and marshaller (serializer)var context = new Jsonix.Context([PO]);<br>
// Then we create a unmarshallervar unmarshaller = context.createUnmarshaller();<br>
// Unmarshal an object from the XML retrieved from the URLunmarshaller.unmarshalURL('<u></u>po.xml',<div><div><br>
// This callback function will be provided<br>
// with the result of the unmarshalling<br>
function (unmarshalled) {<br>
// Alice Smith<br>
console.log(<a href="http://unmarshalled.value.shipTo.name" target="_blank">unmarshalled.<u></u>value.shipTo.name</a>);<br>
// Baby Monitor<br>
console.log(unmarshalled.<u></u>value.items.item[1].<u></u>productName);<br>
});<br>
<br>
<br>
You can try it online in JSFiddle: <a href="http://jsfiddle.net/lexi/LP3DC/" target="_blank">http://jsfiddle.net/lexi/<u></u>LP3DC/</a><br>
<br>
Jsonix is schema-driven. You can basically take an XML Schema and<br>
compile it into JSON-XML mappings.<br>
Jsonix will then be able to unmarshal XML into JSON which is very easy<br>
to process in JavaScript programs.<br>
You can also marshal JSON into XML so you're getting the full<br>
XML<->JSON rountrip for free.<br>
<br>
Java developers out there will defintely recognize similarities to<br>
JAXB. Jsonix is basically a JAXB analog for JavaScript.<br>
<br>
I wrote Jsonix with OGC Schemas in mind.<br>
Here's a WMS demo:<br>
<a href="https://github.com/highsource/jsonix/tree/master/demos/wms" target="_blank">https://github.com/highsource/<u></u>jsonix/tree/master/demos/wms</a><br>
Here's a sample WPS project:<br>
<a href="https://github.com/highsource/jsonix/tree/master/nodejs/tests/wps" target="_blank">https://github.com/highsource/<u></u>jsonix/tree/master/nodejs/<u></u>tests/wps</a><br>
<br>
So if you need a reliable, schema-driven, strongly-typed and structured<br>
XML-JSON conversion for you target OGC spec, you can take Jsonix, compile<br>
your schema and save all those gory XML-to-JSON-and-back details, just<br>
concentrate on your payload in a neat predictable JSON form.<br>
<br>
Jsonix works in most browsers (browser protability is ~ OpenLayers).<br>
Works with node.js. Works with RequireJS. No conflicts with OpenLayers.<br>
Open-source (3-clause BSD), no strings attached.<br>
Heavily tested.<br>
<br>
I'd be very glad if you consider using Jsonix for OWS. I'd be happy to<br>
provide support and help as much as I can.<br>
<br>
Best wishes,<br>
Alexey Valikov<br>
______________________________<u></u>_________________<br>
owslibjs mailing list<br>
<a href="mailto:owslibjs@lists.osgeo.org" target="_blank">owslibjs@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs" target="_blank">http://lists.osgeo.org/cgi-<u></u>bin/mailman/listinfo/owslibjs</a><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
owslibjs mailing list<br>
<a href="mailto:owslibjs@lists.osgeo.org" target="_blank">owslibjs@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/owslibjs" target="_blank">http://lists.osgeo.org/cgi-<u></u>bin/mailman/listinfo/owslibjs</a><br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote><div><div>
<br>
______________________________<u></u>_________________<br>
owsjs mailing list<br>
<a href="mailto:owsjs@lists.osgeo.org" target="_blank">owsjs@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/owsjs" target="_blank">http://lists.osgeo.org/cgi-<u></u>bin/mailman/listinfo/owsjs</a><br>
<br>
<br>
</div></div></blockquote>
<br>
</blockquote>
<br>
</blockquote>
</blockquote></div><br></div>
</div></div></div><br></div>