[Xml-bin] An attempt to sort things out [long]
Stefan Zier
Stefan.Zier@syntion.com
Thu, 19 Apr 2001 11:58:14 +0200
> 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