From: David Corbin <dcorbin@...>
Date: 2002-03-20T00:37:08+09:00
Subject: Re: [ANN] Xml Serialization for Ruby

Massimiliano Mirra wrote:

>On Tue, Mar 19, 2002 at 09:27:55AM +0900, Chris Morris wrote:
>
>>>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?
>>
>
>Exactly.  Consider this:
>
><AddressBook>
>  <Entry>
>    <String name="firstname">John</String>
>    <String name="lastname">Doe</String>
>    <Address name="address">
>      <String name="street">Red Road, 6</String>
>      <Integer name="ZIP">98765</Integer>
>    </Address>
>  </Entry>
>  <Entry>
>    ...
>  </Entry>
></AddressBook>
>
This would also permit you to have a reasonable DTD for this schema, 
where as the reverse ("<firstname type="String">John</firstname>") would 
be  "nastier".  Particularly, when you build more complex objects.

>
>If you want to get all the addresses (and only them) from a file like
>this, you just have to wait for an <Address> element while parsing the
>XML source and marshal it.  If you relied on the top element, you'd
>have to marshal all the address book.  Depending on your application,
>this can be negligible as well as important.
>
>The application for which I hacked XMarshal involved tuples, which
>were represented by arrays.  In that case, I had something like:
>
>["John", /^G/, 12345]
>
>It translated to:
>
><Array>
>  <String>John</String>
>  <Regexp>^G</Regexp>
>  <Integer>12345</Integer>
></Array>
>
>...which you couldn't really express in this form:
>
><Array>
>  <attrname>
>   ...
>  </attrname>
></Array> 
>
>because ``attributes'' (not really class attributes---they were just
>array's content) had no name.  Again, it depends on what the end
>application is going to be, and whether arrays, hashes and other
>containers are going to get in the way.
>
>>>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.
>>
>
>Hmmm, yes, you're right.
>
>>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?
>>
>
>Yes, it does, and I get your point about not forcing it.
>
>>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.
>>
>
>Well, let us know about that, but if you find what feels a better
>approach than C#'s, then by all means go for it. :-)
>
>>Thanks for sending that on. One thing I don't like about the xconv approach
>>is all the if/case-like statements,
>>
>
>Yes, that is not pretty at all, but some classes require special
>handling (arrays and the likes) and some other can be optimized (true,
>nil, false) so that is not too high a price to pay.
>
>>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.
>>
>
>I agree, that feels more OOP to me too.  My application had some
>requirements that prevented that:
>
>- I did not know in advance what classes had to be marshallable;
>- even if I did, I could not create a marshaller object for each of
>  them because there were going to be a lot and performance would have
>  decreased;
>- I could not use a global object either, as the stuff needed to be
>  thread safe, and I could not use a mutex for the same performance reasons.
>
>>Can you summarize your tweaks? And did you fix things like the Hash key
>>limitation (had to be a string, IIRC)?
>>
>
>I added Class, Regexp and Symbol, and yes, hashes containing other
>types can be marshaled.  The tests pretty much cover all the types it
>handles.
>
>
>Massimiliano
>