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] XML Redux


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

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]

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