Re: Proposition for JSON internal storage for XForms

Nick,
>
> ·You could simplify the expressions by removing the '/*/' the  initial 
> context is the root element, so when the context isn't changed you 
> could write "/*/a[1]"  as just "a[1]" (which is more appealing)
>
Yes, I will improve my paper about that.
>
> ·Why use an attribute exsi:maxOccurs and not exsi:is-arry (in the 
> examples only the presence or absence of unbound is used, so it cold 
> be replaced by a boolean)
>
I think that, independently of JSON arrays, defining exsi:maxOccurs and 
exsi:minOccurs might be useful to limit items editing within repeat. 
There is no xsd:is-array, BTW.
>
> ·I don't like the '________' it is hard to remember how many '_' you 
> have to type. Why not use something like "exml:element" (better name 
> is welcome)
>
This element has to be in the empty namespace as others for not 
disturbing the namespace-uri() and name() functions. Its name has to be 
improbable in JSON objects and shouldn't be typed. Better name is 
welcome, of course.
>
> ·I don't like the section 'XPath Engine Proposed Enhancements' because 
> it makes requires you to change the core XPath engine. In my opinion 
> this will do more harm than it does good, because the standard 
> selectors and functions will behave differently if you are accessing a 
> JSON instance and one xpath expression could access both native XML 
> instances and JSON instances. I'm afraid this will be confusing for 
> both novice and experienced XPath users. (we could maybe us 
> json-name() instead of fullname() and maybe do some other small tweaks 
> to make life easier (e.g.: json-node('a')  returns the node with name 
> 'a' in the current context, in XPath 2.0 one can then write 
> json-node('a')[2] or json-node('a')/ b/ json-node('1234').
>
This should not be limited to JSON. vCard is interesting too, CSV 
wouldn't be difficult to integrate either and so on. That's why I 
banished names starting with "json-".

I really think that the single document element restriction in XML 1.0 
is a very bad idea and I hope that next versions of XML will allow 
multiple roots. That's why I'm using "exml:noname" as a dummy element : 
it's a name to be recognized as a special one due to XML 1.0 
limitations. I think the instance() function is more confusing comparing 
it with document() or doc() functions. As you say, the default context 
is already at the document element which is disturbing when used to 
XPath evaluation from other languages.

Calling a function within a path is not permitted in XPath 1.0 and, for 
performance, I consider that a function call is more time consuming 
whereas this can be interpreted,  once for all, at parsing time.

I understand that some implementations are based on external XPath 
engines not allowing to improve the core syntax but just to add external 
functions. XSLTForms (and, as far as I know, other client-side 
implementations written in Javascript) needs its own XPath engine. XPath 
was designed for XML only but there is not much to be added to allow 
using it with other notations.

Thanks!

-Alain