XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xquery-talk] Mistakes made in the design of XQuery 3.1

Hi,
so many recipients. Tempting to add even more.

Too bad it was not discussed on these lists when XQuery 3.1 was still a draft.


I think the array constructor was the biggest mistake. (I believe arrays more frequently used than null)
I doubt it would be possible to make a worse definition.

Three constructors, map { ... }, array { ... }, [ ... ]

Only [ ... ] looks out of place.

Every other constructor in XQuery uses { }. Even node constructors.

There is no reason to add [ .. ] for arrays, if you want to make a consistent language.
Especially adding [ ... ] but then not a raw { ... } for objects.


Anyways, assume someone really wants to have an abbreviation, because they like JSON or JSONiq.

How would you define the semantics of the constructors?

Use comma to separate members or as XQuery comma operator concatenating sequences?


What does it do in JSON?

There are no sequences

What does it do in JSONiq's [ ... ]?

It does concatenate sequences.

What does the other new constructor similar to array { } do ? map { 1 : (2,3), 4: (5,6) }

There , does not concatenate sequences.


So the only reasonable definition is to concat sequences in [ ] and not concatenate them in array { }


But no, you do the complete opposite!



Conclusion: The [ .. ] constructor was just put there to annoy JSONiq users. That is the only explanation.

So an usual query that creates arrays cannot be a valid JSONiq and XQuery 3.1 query at the same time.



Best,
Benito



On 05/09/2015 08:44 PM, daniela florescu wrote:
BTW,

not only I don’t think that XQuery 3.1 didn’t bring any major technical advantage compared to JSONiq, I think some of the choices are simply
damn WRONG, and with long term negative consequences.

I can write a long email about that, but I don’t have time, and honestly, now I care more about Augmented Reality and 3D graphics
then I care about XML and JSON.

I will mention only the biggest mistake I see: the modeling of the JSON  NULL value as an empty sequence.

Do you really think we were silly in the design of JSONiq when we made it a separate value,  different from all other values !? No, we did it on purpose,
and with avery clear goal : to be able to control it’s semantics.

If you map the JSON NULL into the empty sequence, then the NULL will automatically behave in all operations (comparisons, arithmetics, etc)
as the empty sequence does in XQuery.

Unfortunately the semantics that XQuery has for the empty sequence is ***different*** from the semantics of NULL in the NATIVE language of JSON: Javascript.

Right there, by this “small” decision, you made XQuery 3.1 unusable, hated, and unused in the Javascript community, and you made the XML
community to NOT be able to work together with the JSON community.


Great achievement, lots of thinking…..W3C people ….. (it’s ironic..)

Dana



On May 9, 2015, at 11:31 AM, daniela florescu <dflorescu@me.com> wrote:

Michael,

I think I didn’t make myself clear.

The purpose of a standard is to increase interoperability in the world.

The decisions that were taken in the case of XQuery 3.1 do exactly the opposite, WITHOUT bringing in any major technical
advantages.

That’s all I am trying to say.

JSONiq is 3 years old, implemented by a variety of systems, and used in production in many places. And it was very well
designed: 2 years of VERY CAREFUL design by very good engineers went into the design of JSONiq.

Plus JSONiq will CONTINUE to be used widely in the NOSQL community, simply for the following two reasons:
(a) it has a JSON-only subset that makes sense for the JSON-only community (who in general doesn’t want to see any shadow of angle brackets) and
(b) has the great advantage that doesn’t have the hated word “Xquery” in its name.


By not following JSONiq, by taking “slightly different” choices, or by not trying to extend it, XQuery 3.1 just broke the interoperability
in the NOSQL community, and this is what I consider a total lack of vision from the “leaders” of this community.

Let’s look again of the differences you mentioned between JSONiq and XQuery 3.1. I quote:
***********************************************
At the data model level:

* Maps can use any atomic value as the key, it does not have to be a string
* The members of an array are sequences, not necessarily items
* JSON’s null is represented as an empty sequence, not as a new atomic data type

At the syntax level:

* In XQ3.1, Map constructors use the syntax map{ a:b, c:d } rather than bare curlies
* XQ 3.1 introduces a lookup operator for maps and arrays: employee?name, or book?author?1
**********************************************


Now, dear Michael, ask yourself the following questions:


*********************************************
1. Was there any “mistake”, or “bug”, that was in JSONiq that those choices solved ?
I am not aware of any.

2. Are any of those choices “fundamental’, aka introduce a much larger expressive power, make the language much easier to use, etc.?
Anything fundamental in those “new” choices ?
Nope, they are just small, mostly insignificant, just enough itsy bitsy differences to confuse and irritate the entire NoSQL community.

3. In case where a larger expressive power was desired, wasn’t it better to extend JSONiq in an upper compatible way, rather to take a different route ?

4. Did XQuery 3.1 “committee” ever tried to contact the JSONiq community to try to find common solution that would eventual lead to a single, better language ?
ALL decisions we took in the design of JSONiq were definitely not random, but VERY carefully thought out. You were not even curious of what those reason where,
(and sometimes XQuery 3.1 got it totally wrong — I an write you a long email about THAT).
*********************************************

So: no bugs to be fixed, no new major technical advantages, and no desire to cooperate.

What conclusion do you get from here ?

I get a single conclusion: the XQuery 3.1 committee has a total lack of vision and leadership in the NoSQL world.

This can has two possible explanations: pure stupidity and lack of good will.

I am trying to be nice, and pick the second choice among those two…..you see.

No wonder that because of silly decisions like this they will make XQuery to become irrelevant in the NoSQL world. No wonder the Cassandras, the Mongos
and the BigTable and all other JSON databases of the world will ignore what you “decided”, deal Michael Kay and other W3C people.


And that’s a pity because  XQuery could have contributed quite a bit to the NoSQL world. XQuery has an experience of 16 years of processing semi-structured
data that those guys have no clue about (most they don’t even understand what they don’t know).

You made a HUGE political mistake in the design of XQuery 3.1. by fractioning the community.

And this: for no technical gain AT ALL.

The community looses, and I can see only two “people” who beneficiate (only short term) from this schism: Saxon and MarkLogic.

Long term everyone looses from those stupid decisions.

Dana













On May 8, 2015, at 4:09 AM, Michael Kay <mike@saxonica.com> wrote:

So, to me,  the decisions of the W3C working group seems random, and rather based on a two years old
kind of a  tantrum “I WANT TO BE DIFFERETENT JUST BECAUSE…..I WANT IT."


……...rather then justified by any technical reasons.

No, all the arguments were all technical. For example:

* generalizing maps to allow any atomic type as the key, rather than only a string, was because of specific use cases that required this (remember that the first proposal to add maps to XDM came from XSLT streaming work, not from JSONiq)

* the decision to use “map{…}” rather than “{…}” was to some extent subjective, but was motivated by technical arguments such as the ability to produce good error messages, retaining options for future extensions to the grammar, etc. Expressions beginning with “{“ are particularly problematic because “{“ is used to delimit embedded expressions in element content, and “{{“ is used to escape “{“ as an ordinary character; they are also very obscure when used as the body of a function (declare function f {{1:2}}). Before making this decision, we looked at how many other popular languages solve this problem.

* the decision to allow any sequence to act as a member of an array enabled things like the fn:apply() function, whose second argument is an array of arbitrary sequences; it also enabled JSON null to be represented by an empty sequence, which avoided the need for pervasive changes to the language to define how every function and operator should handle a JSON null. Reducing the number of concepts by one is a definite plus.

Getting agreement on all these points was a very lengthy process with much heated argument. Although the decisions made were not always the ones I personally advocated, I think the final language works well. If there’s one aspect I’m still a little unhappy about, it’s the fact that an array behaves like a single item, so for example

let $A := [1,2,3]
return $A[1]

returns [1,2,3]

But that’s there because we tried very hard to find a way to avoid this surprise, and failed: the sequence=item model in XDM is just too deeply embedded.

Michael Kay
Saxonica

_______________________________________________
talk@x-query.com
http://x-query.com/mailman/listinfo/talk







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS