[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Redux
But what if you placed the same constraints upon an E4X representation as you do within JSON - no evaluative constructs. For instance,
// myJAXON.js {"firstname":"John", "lastname":"Cowan", "signature":"xml(<div>It was the <i>best</i> of times.<br/>It was the <i>worst</i> of times.</div>)"}
Doug Crockford has made a repeated point that JSON should in general not be straight script eval'd but should be parsed, and I think that holds for XML representations as well. An E4X aware parser would then handle the relevant parsing into an object with both XML and Javascript object NVPs.
var record = JAXON.parse('myJAXON.js') echo(record); // {firstname:"John", lastname:"Cowan", signature:new XML(<div>It was the <i>best</i> of times.<br/>It was the <i>worst</i> of times.</div>)};
which could then be accessed using an E4X engine: echo(record.signature.i[0]) // <i>best</i> while a non JSON parser would at least recognize that it's a string that could be parsed if xml() became convention:
var node = JSON.parseXML(record.signature); Any brackets within the JAXON XML stream would be treated as text, and not evaluated. All it would take is the establishment of a convention on the XML side.
Problem is that it's not always the same 80/20. For HTML, namespaces are awkward and irrelevant. For what I do (working with large governmental schemas such as XBRL, NIEM, Premis and so forth), they're essential. Any place where I need to provide validation of mixed schemas, such namespace separation becomes critical. Quoting attributes or even using attribute labels with no associated value is not as major, but does require that a schema exist that can identify a default value at some point, because a map is, by definition, a name/value pair set. Comments are useful for any number of reasons. Entities - personally, I think that if you expanded the list of valid entities to the HTML set by fiat, not a lot of people would lose sleep over them. On the other hand, I think that there is value to expanding the notion of XML to include sequences and other features that are part of the XDM; so long as we have a consistent mechanism for identifying such a sequence, there's no real reason why an XML parser couldn't create a corresponding array of nodes rather than just one (certainly XPath2 recognizes this concept).
As I see it, the XML-prime laundry list from the HTML side looks something like:
I may have missed an edge case in there perhaps, but that seems to be the crux of the requirements after two months of discussion. It would not be backward compatible (XML-prime would not be parseable with XML 1.0 parsers). In addition to that, I think there are a few other nice-to-haves that might be worth thinking about
Given my druthers, I could live with the above, most of the changes involved would be a reflection of what is increasingly common, accepted usage. It would require that the schematic models be changed somewhat to reflect the looser notation on elements and attributes, and it would take a while to propagate through the toolsets, but its doable.
However, that would mean that the HTML working group would have to concede that HTML is in fact an instance of this new XML-prime, and that SOME form of mechanism would need to be incorporated such that the above could be incorporated into the web browser space. Maybe it's an E4X, maybe it's better XPath support, maybe it's XQIB, but I think what the XML side is looking for is a way to consistently unify the two standards so that server side developers working within an XML context are not going to be tripping over HTML.
Kurt Cagle
[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
|