> 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.
Perhaps Dan meant "wrapper" or "envelope" when he said "header", but
its not clear to me without an example. So, I'll put some examples out
there for folks to throw stuff at:
Here's an example of a Parrot Magic Ice (PMI) header (no love here from
XML folks):
<pmi class="foo" .../>
# Data of some sort determined by class foo
(This is the way I read Dan's original comment.)
Taken in its entirety, this chunk isn't XML. Sure, you could pull out
the first line and pass it to something that understands XML, and it
wouldn't choke. But, if there is value here, I'm missing it. It could
just as well have been SMTP style:
PMI-Class: foo
Some-Other-Header: ...
# Data of some sort
Here's an example of a wrapper:
<pmi class="foo" ...>
<!-- Data of some sort determined by class foo -->
</pmi>
That's a bit better, although bear in mind that if the intent is that
you could throw the entire chunk at an XML parser and have it not
complain, you are going to have to take some care in generating the
guts. Binary data is in general right out (where does it end? What if
it contains fragments that look like XML markup?). Sure, you could
slap it in a <![CDATA[ ... ]]> film, but you'd still have to watch
out for the possibility that the body might want the sequence "]]>"
in it somewhere...
.............................................
OK. Now, I'll throw one crazy idea into the mix. Suppose for just a
moment that instead of using XML proper, or leaving things completely
open-ended, we adopted SAX events as our interchange. it would be
roughly equivalent to:
begin-element pmi { class => 'foo' }
# events for the guts
end-element pmi
Now, anyone who likes XML can hook up a DOM tree builder, or an XML
renderer to the stream of events and be happy as a clam. But, for
storing stuff on disk, we are free to invent a more compact
representation of the events. Thawing entails interpreting the events
as object allocations and state changes to the objects.
I can imagine some reasonably compact representations...
Regards,
-- Gregor
--
Gregor Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
