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: [xml-dev] James Clark: XML versus the Web

I sense a sea change underway, and personally I think it's about time.

DOM is certainly one of the key problems. That's been apparent for a long time, and I think the existence of both XQuery and JQuery point to the fact that neither community have been particularly happy with having to manipulate complex SGML-esque data structures using tree walkers. I'd argue that had XQuery come out much earlier than it did, roughly along the timeline of the big three XML standards (and prior to the AJAX explosion starting in 2004), then there's a good chance today that we might be using XQuery within browsers, because it is a cleaner way of directly accessing and processing nodes. 

JSON's structure is isomorphically a subset of XML's - you can in fact represent any JSON within XML, but there are XML structures that cannot be represented within JSON. Nor is JSON terribly useful for the representation of documents, and at least on the server side one of the things that becomes evident to me is that we're moving into a realm where data/document hybrids are in fact increasingly the norm.

As a thought experiment, has anyone ever tried to model JSON as an SGML language? Especially if you treat XML as a base nodal type rather than as a string, it's not hard to see constructs like:

{<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 not dissimilar to an XQuery sequence:

(<foo><a>This is a test.</a><b>This is only a test.</b></foo>,element bar {(element a "This is a test.",element b "This is only a test.")},element bat {(<a>This is a test.</a>,element b "This is only a test.)})

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

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




[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