From: Massimiliano Mirra <list@...>
Date: 2002-03-19T21:22:42+09:00
Subject: Re: [ANN] Xml Serialization for Ruby

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>

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