JSONiq for XML DBMSs vs. simple import/deserialization

[Johannes Lichtenberger]

Hello,

I'm developing a versioned XML (and probably JSON) storage system[1] which should emerge into a full blown database system someday (also added Gishlain's temporal XPath axis which are supported by the TimeMachine). However I'm currently thinking about adding JSON support. I could simply add object/array record types which would align with Brackit(.org) (which I'm using as the XQuery processor). However I'm not sure if it's generally a good idea to introduce new records (as for instance required by the JSONiq extension to XQuery or simply to map the JSON types during import/serialization. As posted in another thread I think the navigation in JSON isn't nearly as nice as with XPath. Clearly serializing the JSON to usual XDM types has the advantage to simply reuse index-structures, to reuse XDM creation factorys, to simply use XPath and XQuery... however it restricts the user to an ordered tree-model.

kind regards
Johannes

[1] https://github.com/sirixdb/sirix

[Ghislain Fourny]

Hi Johannes,

Many thanks for your feedback.

If I correctly understand, you are comparing the following two alternatives:
1. Enriching the data model with new items (objects and arrays). This is what we call the JDM (JSONiq Data Model).
vs.
2. Reuse the existing XDM data model, and map (parse) JSON syntax to, say, XML elements in a special way.

I think there are several mappings that were designed that do the JSON->XML (or XDM) conversion. Indeed, you can then use the power of the XPath syntax. I think Zorba has (or at least had at some point) functions to do that. Both approaches make sense to me.

We consciously took approach 1 in JSONiq. Our rationale was the following:
- We think JSON deserves to be a first-class-citizen in the NoSQL world, just like XML. Many databases, like MongoDB, are JSON (or BSON)-focused.

- JSONiq now designates a language that was forked from XQuery and that specifically addresses JSON querying (no XML in its core). Having a JDM is logical in that respect -- even though both JSONiq (extended with XQuery) and XQuery (extended with JSONiq) can do XML and JSON simultaneously.

- The main attribute of JSON is (I think) its simplicity -- probably, or partly, because it is data-oriented, whereas XML also covers the document-oriented space (publishing, books, XHTML...). JSONiq with JSON support only is simpler than XQuery.

- It comes at the cost of a much simpler navigation syntax (no going back to the parent, ...), but I am tempted to say "it's not a bug, it's a feature", or at least a design feature :-) Since it is Turing-complete, one can always write function libraries that provide a more complex and powerful navigation experience, possibly with an optimizer under the hood.

- We are currently fine-tuning the JSONiq navigation syntax. While it will not add any complexity, we think it will give it a feeling a wee bit closer to XPath.

I hope it makes sense?

Kind regards,
Ghislain


On Jun 13, 2013, at 10:51 AM, Johannes Lichtenberger <lichtenberg...@gmail.com>
wrote:

> --
> You received this message because you are subscribed to the Google Groups "JSONiq" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jsoniq+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Johannes Lichtenberger]

Am Donnerstag, 13. Juni 2013 11:43:48 UTC+2 schrieb Ghislain Fourny:

Hi Johannes,

Many thanks for your feedback.

If I correctly understand, you are comparing the following two alternatives:
1. Enriching the data model with new items (objects and arrays). This is what we call the JDM (JSONiq Data Model).
vs.
2. Reuse the existing XDM data model, and map (parse) JSON syntax to, say, XML elements in a special way.

Yes, however I'm still not sure. In my case it's very simple to add new items (objects and arrays) and it would align with the Brackit(.org) approach (they might implement JSONiq, I'm not sure -- at least it's very similar). Or I'm able to implement the JSONiq extension myself. However, in the long run new index-structures have to be implemented along with functions (which I'm currently implementing for the XML part ;-)), rewriting rules...
 

I think there are several mappings that were designed that do the JSON->XML (or XDM) conversion. Indeed, you can then use the power of the XPath syntax. I think Zorba has (or at least had at some point) functions to do that. Both approaches make sense to me.

We consciously took approach 1 in JSONiq. Our rationale was the following:
- We think JSON deserves to be a first-class-citizen in the NoSQL world, just like XML. Many databases, like MongoDB, are JSON (or BSON)-focused.

- JSONiq now designates a language that was forked from XQuery and that specifically addresses JSON querying (no XML in its core). Having a JDM is logical in that respect -- even though both JSONiq (extended with XQuery) and XQuery (extended with JSONiq) can do XML and JSON simultaneously.

- The main attribute of JSON is (I think) its simplicity -- probably, or partly, because it is data-oriented, whereas XML also covers the document-oriented space (publishing, books, XHTML...). JSONiq with JSON support only is simpler than XQuery.

- It comes at the cost of a much simpler navigation syntax (no going back to the parent, ...), but I am tempted to say "it's not a bug, it's a feature", or at least a design feature :-) Since it is Turing-complete, one can always write function libraries that provide a more complex and powerful navigation experience, possibly with an optimizer under the hood.

- We are currently fine-tuning the JSONiq navigation syntax. While it will not add any complexity, we think it will give it a feeling a wee bit closer to XPath.

Everything makes perfect sense. However, probably it adds a lot of additional complexity for XML database systems (I guess some systems inherently can never support addtition data types). In my case I would be able to store every kind of datatype provided that a custom serializer is plugged in. Hm, but I'm not sure how to integrate the new types (probably have to reread the JSONiq for XQuery document), but it should be fine to add arrays/objects anywhere, where usually elements could be inserted.

kind regards
Johannes