Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: James Clark: XML versus the Web
 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:
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
