From: Chris Morris <chrismo@...>
Date: 2002-03-19T09:27:55+09:00
Subject: RE: [ANN] Xml Serialization for Ruby

> These two are mostly equivalent.  The main reasons I prefer the first
> are 1) since the element name is the class name, you can always
> extrapolate an element and easily marshal it into an object

I'm not sure I follow you here. Are you saying that with class name as an
element it's required to be there, therefore you can "always" read it in --
whereas with an optional type attribute, you might get stuck?

> 2)
> available classes are a finite number while attribute names are
> virtually infinite, so it might be easier to validate a document in
> the first case.

Hmmm ... again not following exactly. If the root node was required to be
class name (which I'm leaning towards), then you'd still have that to match
against the finite set of classes, then assume the rest of the element names
matched existing instance vars.

I guess I'm thinking that no matter how it's sliced (how the xml is
formatted), there's still going to have to be a class that matches the
structure of the xml, and one format doesn't buy me any assurances over
another.

Maybe I'm not getting your point.

> Just keep in mind that preserving type information in XML might help
> you detect whether you are trying to marshal an older or different
> format to the current implementation---where, for example,
> <customer></customer> might be of class Customer now, whereas it was
> String in the previous implementation...

Yes, but I'd like the option to not force type info in there. If I'm just
doing a simple thing and all the type info is getting in the way, I want to
be able to turn it off. I plan on supporting full type info if you want
it -- but your formatting requires me to have it, right? (I could probably
easily support both approaches, esp. since the current code is very similar
to your formatting)

I know my suggested formatting has a smell to it that yours doesn't. I wish
it didn't, because I still think I want to keep the smell ... more on that
next...

> (Well, dynamic doesn't mean untyped, it just means dinamically typed,
> doesn't it?)

Yeah, I was throwing around those terms a bit loosely :)

> If you *really* want to follow that scheme, I'd suggest just adding
> the special name ``root'':
>
> <root type="MyClass">
>   ...
> </root>
>
> ...and possibly make all the type attributes inside root optional.  At
> least it would stop mixing class names and attribute names as the
> element names.

I agree that that smells ... the inconsistency of "root element is class
name, all other nodes are instance var names" ... but I'm almost positive
this is how C# does it, and when I was working with it felt quite natural
from a 'user' standpoint. The inconsistency never occurred to me until now.
Of course, I need to double check -- work has detoured me from my C# lately.

> And if also you want to consider the other way, watch your
> mailbox. :-)

Thanks for sending that on. One thing I don't like about the xconv approach
is all the if/case-like statements, and everything being contained in a
standalone processing class. My approach actually adds to_xml/from_xml
methods to the standard classes and classes with the module include, so it
feels more OOPy to me.

Nevertheless, there are good things in there I can pick out (like I just
skipped over doing RegExp, but it's included there ... of course I've
included Time and it doesn't appear to handle it).

Can you summarize your tweaks? And did you fix things like the Hash key
limitation (had to be a string, IIRC)?

Thanks a bunch for all the feedback! And I'm glad you've got some different
desires on this, because so far I'm pretty confident it can all be
supported -- that should just make it more robust.

Chris