Indeed, replace the formal "element a b" with *a:b, and the sequence becomes even closer:
(<foo><a>This is a test.</a><b>This is only a test.</b></foo>,*bar:(*a:"This is a test.",*b:"This is only a test."),*bat(<a>This is a test.</a>,*b:"This is only a test."))
This is then where XQuery shines over JSON:
let $seq := (<foo><a>This is a test.</a><b>This is only a test.</b></foo>,*bar:(*a:"This is a test.",*b:"This is only a test."),*bat(<a>This is a test.</a>,*b:"This is only a test."))
let $bset := $seq/*/b
return count($bset)
=> 3
let $only-set := $seq//*[contains(.,'only')]
return count($only-set)
=> 3
The other issue is in invocation of functionality - XQuery assumes a declarative modality with no intrinsic semantics, whereas most AJAX libraries assume that objects attached to a given node are in fact functions. This opens up an interesting can of worms, but again, there may be some syntactic sugar that may simplify things.
Suppose, for instance, that you introduced dot notation (which removes dots from variables, but I've always thought that was a bad idea anyway), and performed a direct invocation on the object:
$a.ns:bas($foo) := ns:bas($a,$foo)
In the case where the object being defined is in the same namespace as the function, this would simplify to:
$a.bas($foo) := bas($a,$foo)
Maps (such as those implemented in eXist and MarkLogic) are a good test case for that (I'm assuming that map:put() returns the map object)
let $myMap := map:new().set("a",5).set("b",10).set("c","test")
return $myMap.get("c")
=>"test"
JavaScript is similar, save that it's not as robust wrt namespaces:
var $myMap = (new Map()).set("a",5).set("b",10).set("c","test")
output($myMap.get("c")
The point I'm trying to make here is that the XML community has had a tendency to become fixated upon the document rather than upon the sequence. You cannot represent a sequence with XML - by definition. You always have to have a root node. Because of that, I think its created a lot of blindness in the community about the limitations of XML, and let those technologies that do not have such a blind spot leap over XML. This isn't obvious within XML or even with XSLT (which was similarly seen as working on documents) but in XQuery this blind spot is VERY evident.
Personally, I don't necessarily see trying to refactor XML so that it can be represented as JSON is a good idea - it misses the point that there are reasons why the infoset model is superior to the JSON model. However, if the two communities were to meet half-way - to treat XML as first class objects within the browser (which was what E4X was trying to do, something the XML community should have been behind years ago), to make a more concise XQuery notation, and to start working with groves (yup, there's the word) instead of point documents, we'd likely ease a lot of the standoff between the HTML5 and XML factions and provide some value to the technologies' users as well.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
On Sat, Nov 27, 2010 at 8:12 AM, David Lee
<dlee@calldei.com> wrote:
Rick Says -===
-----Original Message-----
From: rjelliffe [mailto:
rjelliffe@allette.com.au]
Sent: Saturday, November 27, 2010 12:37 AM
To:
xml-dev@lists.xml.org
Subject: Re: [xml-dev] James Clark: XML versus the Web
XML v JSON
Does it have to be either/or, in our imagination?
There 2 other approaches to XML "vs" JSON (there are many but here are 2 ...)
1) XML parsers in the browser. Yes its been nagged to death but IMHO that Is the #1 reason JSON is used, because its 'trivial' to turn into Javascript objects, but not XML (in all environments). I know people are finally giving in and accetping that "JavaScript is the VM of the Browser" (we had this argument last month).
We may not like it but it appears to be fait accompli.... So why not learn to love the bomb ?
Browser venders are not coming to the rescue so why not a JS project for converting XML to JS objects that’s as easy to use and as fas as eval(JSON) ?
It doesn’t need to be perfect or handle All XML (IMHO). Atleast in the space I work most in (Mobile device) people target data for Javscript apps explicitly. On the server ... I'd much rather chew up a complex XML doc into a simplier one then have to produce JSON to send to the client.
I've heard hints that maybe XQuery & XSLT devs are experimenting with this.
2) Clean (possibly lossless) XML<->JSON transformations
This is something I've been working on in my spare time. I hope to have something of quality by next year (and hope to submit a paper to Balisage).
I was encouraged by the reception of my ad-hoc presentation this year that I'm continuing the work. I have an early-prototype implementation working well. I'm willing to accept that XML 'isn't wanted' on the browser even though that is what XML was intended for originally .. it just didn’t happen. While hoping this will change in the future, A next-best-thing is a good clean technology for translating XML-JSON both ways and produce JSON AND XML that the respective developers would actually want to use.
When that happens, the argument could end (except for the purists).
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
