[Xml-bin] An attempt to sort things out [long]

[Stefan Zier]

> Nope, unilaterally suggested by yours truly. The crux of my point was to
> try to reuse the <?xml as a header, y'see.

Might get a lotta people confused though. Looks like XML but isn't XML ;)

> > Otherwise, why not go ahead and use the encoding
> > attribute, I think this could be a meaningful application of it.
> I dunno, wasn't that meant to refer to *character* encoding?

Yup, you're right... Then I think I'd rather have a different header.

> The two are semantically identical, though - whether to make the file
> SAX-like or DOM-like are just issues of how to represent an XML document
> in a binary format, as I see it (kick me if I'm being thick, it happens).

Well, on a logical level the question is do we represent the _document_ or
what single APIs make out of it - on a technical level I have to agree that
the encoded document and the encoded SAX event stream ar - by the nature of
SAX - pretty much the same. Still I think we need to get some light into the
question.

> The ASN.1 <-> XML effort seems to be covering the SAX-like approach of
> just representing the document structure in a binary manner, currently,
> but doesn't look likely to be optimised for extracting snippets in an
> XPath like manner, which the DOM one would have.

Sounds like DOM is the way to go then. But then let's rather call it a
binary encoding of a DOM tree than a binary encoding of an XML document
(although the DOM tree is a representation of the XML document).

> I'm proud to say that Olivier's invitied me to join the ASN.1 <-> XML
> working group :-)

Great! Congrats. Maybe you can leverage the experience you gathered in that
WG for the binary DOM representation.

> Therefore, I'd be inclined to say that we ought to be focussing on a
> "DOM-like" representation of an XML document in a binary file, meaning
> that DOM tree operations should be implementable in constant time (eg, the
> element gives pointers to its children that can be followed directly
> rather than requiring parsing of all the children to find the desired
> one).

I agree...

---------------------------------------
Stefan Zier
Software Developer
Syntion AG - http://www.syntion.com
Leonrodplatz 2 - 80636 Munich/Germany
Phone +49 89 52 30 45-0
Fax +49 89 52 30 45-20