Re: [xml-dev] XML Redux

I can give you an example. Let's say that I'm using something like a MarkLogic database that can both generate and read JSON and I want to encode XML within that JSON construct. ML will take that JSON and create what's known as a map structure, which structurally is similar to the JSON structure. This is an in-memory structure. With the JSON encoding that you've given below, the map would, a priori, not know that it was dealing with an XML structure until such time as a namespace was declared, and as it sits now would still serialize this into XML as a property-centric notation that may or may not be transformable to an XML structure via XSLT, and then only after serialization and reparsing of that structure. It's also a notation that, paradoxically, will add considerably to the overall size of the XML document in most cases - that is to say, as a wire format, it's less efficient as a transport mechanism compared to XML natively (this is not true of JSON in general, but it is true of JSON encodings of XML).

Perhaps this is acceptable. If that is the case, it would necessitate that there be a formal standardized�mechanism that describes the conversion to and from XML that is recognized by the relevant standards organizations, simply because without that there is no guarantee of interoperability. RIght now I believe there are three or four such conversion mechanisms, and no clean way of differentiating, a-priori, WHICH of these is being used to encode a given XML structure. It may be that the best such conversion is one that corresponds most closely to the EXI standards, but I'm not sure about that one.

Put another way, given the presence of the json conversion functions within HTML 5, it may prove worthwhile for the HTML working group to publish the JSON-XML conversion spec which provides the best lossless encoding, along with a similar conversion that will create a standardized XML format that can be used to formally encode a JSON object as XML with no formal semantic knowledge of that object going in. This way, XML and JSON databases can reliably communicate with one another and JSON objects can be searched in an XML context. Because the underlying data algebra is different for the two specifications, this is likely not a trivial undertaking, but it DOES provide a first level unification of the two standards, which is what ultimately I believe is one of the goals of this group.

Kurt Cagle

kurt.cagle@gmail.com

443-837-8725

On Mon, Feb 21, 2011 at 2:34 PM, John Cowan <cowan@mercury.ccil.org> wrote:

Kurt Cagle scripsit:

> 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),

Oh, I see; you want a conventional way of *embedding* XML in pure JSON,
as opposed to an *extension* of JSON. �I didn't realize that. �In that
case, I'd rather use the style in which

� � � �<a href=""http://example.com">This is <i>mixed</i> text</a>

becomes

� � � �{"#name" : "a",
� � � � "#attrs" : {"href" : "http://example.com"},
� � � � "#children" : [
� � � � � �"This is ",
� � � � � �{"#name" : "i",
� � � � � � "#attrs" : {},
� � � � � � "#children" : ["mixed"]},
� � � � � �" text"]}

Verbose, but it requires only one parser, not two.

--
John Cowan �cowan@ccil.org �http://ccil.org/~cowan
If I have seen farther than others, it is because I was standing on
the shoulders of giants.
� � � �--Isaac Newton