On Mon, 20 Oct 2003, Gregor N. Purdy wrote:
>
> > the xml header is only for the top level thing in the serialized
> > tree. if it is nonstandard you have to mark the serialized string so you
> > can call the matching thaw methods. each object in the serialized tree
> > will have to support that method or some code has to be supplied to
> > handle all the freeze/thaw calls made by the tree traverser code. so the
> > xml header is just a way to mark which external class will be used for
> > the freeze/thaw and it will always be called for each object in the
> > tree. you can't mix/match different freeze/thaw techniques in one
> > operation (yes, you could but then you do have to mark each node with
> > its technique which is a lot of overhead and painful in other ways).
>
> I find the notion of an "XML header" a bit confusing, given Dan's
> statement to the effect that it was a throw to XML folks.
>
> I think anything "XML folks" will be interested in will entail
> *wrapping* stuff, not *prefixing* it.
Nah, I expect what they'll want is for the entire data stream of
serialized objects to be in XML format. Which is fine--they can have that.
(It's why I mentioned the serialization routines can be overridden)
For an XML stream the header might be <xml parrot format='xml'
version=1.0> with the rest of the stream in XML. A YAML stream would start
<xml parrot format='yaml' version=1.0> with the rest in YAML, and teh
binary format as <xml parrot format='binary' version=1.0>. Or something
like that, modulo actual correct XML.
This way we have a single, fixed-format type/version header, which makes
the initial identification easier and less error-prone. (Possibly even
fit for file and programs of its ilk to note) The binary format won't
care, and teh YAML format shouldn't care (as long as the indenting's
right) but the XML format would, so it seems to make sense to use the XML
stuff for the initial header.
Dan
