Re: Mistakes made in the design of XQuery 3.1

[Michael Kay <mike@saxonica.com>]

> 
> 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.
> 

You can be assured that we had lively debates on this topic, and there were good arguments to be made both ways: none of them at all silly.

The use of empty sequence to represent absence of a value is very pervasive across all the functions and operators of the language. Many people felt that having two different ways to represent the absence of a value would just be too bewildering and too complex, and that few users would understand the subtle differences between them. If null can be supplied as an operand to comparisons, arithmetics, and to functions, then we not only need to define what every function and operator does when null is passed, we probably need to extend the type system so a function signature can declare that an argument is “nullable xs:integer” (i.e. the union of xs:integer and null), and we then have to teach users the difference between xs:integer? and “nullable xs:integer”. You even have to consider the type null? which is either null or empty. And we would almost inevitably have some functions returning () and others returning null to mean essentially the same thing - no result. People would have to check the spec every time they can’t remember which variety of null a particular function uses.

We were aware, also, that XQuery has two equality operators, and Javascript also has two, and none of them quite do the same thing. We didn’t want four equality operators. Unambiguous mapping of the JSON data model to XDM was an objective, but replication of the semantics of Javascript operators wasn’t.

Michael Kay
Saxonica