[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Redux

  • From: Kurt Cagle <kurt.cagle@gmail.com>
  • To: John Cowan <cowan@mercury.ccil.org>
  • Date: Mon, 21 Feb 2011 13:43:40 -0500

Re:  XML Redux
John, 

I understand what you're trying to say: "Wouldn't it make more sense to use XML itself as the delimiter characters?"

{"field":<foo>This is a field</foo>}

And yes, I agree with you, my preference would be to go that route as well. The problem is that most JSON out there doesn't play by Doug Crockford's rules where you have a string that is formally parsed. Instead, it IS eval'd, which of course defeats the whole purpose of having a safe format, but there is probably as much malformed JSON out there as there is malformed XML (maybe more).

What this points to is that either the corresponding JSON libs would need to be adapted to properly parse XML blocks (which would be lovely, but which I'd say is about as likely as Hixie suddenly becoming an ardent XML-phile), or alternate mechanism would need to be provided that would make it clear to a JSON post-processor that the string in question is in fact legitimate XML content that can be parsed as XML after a simple regex transformation.

I wish it were different, but this is one of those cases where a small change in convention on the XML side could make it easier to identify embedded content in a consistent manner, whereas it would require significant behavioral change from a large and fairly hostile AJAX development community. In this case, the pattern /\"[Xx][Mm][Ll]\((<.*?>)\)\"/ would end up establishing the delimiters.  

Kurt Cagle
Member and Invited Expert
XForms, HTML Working Group
World Wide Web Consortium
443-837-8725



On Mon, Feb 21, 2011 at 1:17 PM, John Cowan <cowan@mercury.ccil.org> wrote:
Kurt Cagle scripsit:

> That could work too. However, I'm just thinking of the use case
> {"button-label":"<<< Previous <<<"}.

That is a quoted string, ergo not an XML element.

> "xml(<test>This is a test.</test>)" is both less ambiguous and far less
> likely to occur as part of a random JSON expression.

I'm not sure whether those quotation marks are metalanguage or not.
If they are part of the syntax, then yes, you have a problem; stuff
in quotes should always be a literal string.  Otherwise, there is no
possibility of confusion between these:

  {"foo": "<bar/>"}    -- value is a string; JSON or JAXON
  {"foo": <bar/>}      -- value is an XML element; JAXON only

--
John Cowan   <cowan@ccil.org>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher



[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.