[xquery-talk] [xml-dev] Mistakes made in the design of XQuery 3.1

[daniela florescu]

> 
> I get why SQL is not an appropriate basis for a language for these data stores but I don't yet see how we make the leap from XQuery being a language for particular types of semi-structured data to it being the basis of a query language suitable for semi-structured data in principle, unless you are talking in very broad terms about the features such a query language should have and what principles should guide it's design.

Ihe,

I gave you a general answer in the previous emails.

Yet I have to remark something before I shut up.

Our work in JSONiq applies to JSON. Period.

Not all NoSQL databases use JSON as a data model (or syntax, whatever) - some use it just a simple 
add-on, or import/export syntax, similar to CSV.

The problem of building a good query language for those NoSQL databases starts with the fact that 
THEY HAVE NO CLEAR DATA MODEL of the data they store. Not even sometimes of what basic types
they can store (e.g. ask Cassandra people if they can store dates, and you’ll get a very convoluted answer…)

Most of the times the “data model” is just an implicit assumption behind the API calls that you can make to that database/datastore.

I don’t know how to build a good query language, unless I have a logical model of the data being queried… it’s that simple.

At least JSON… I understand JSON… so I can build a query language for it….

It’s not a value judgment  (aka "JSON is better”), it’s just that it’s there, it’s well described, and people use it everywhere.

Best regards
Dana