Re: XML Parsing the Ruby way.

On Sat, 2003-04-26 at 21:28, [e-mail] wrote:

> There was an discussion on xml-dev on the tree-ness of XML:
> http://aspn.activestate.com/ASPN/Mail/Message/xml-dev/1556296
> 
> I tend to side with the "it's only a tree if you want to see it that
> way" view.

I agree, though I choose to see it as a graph (with a tree being a
commonly found subset of that).  I see a collection of documents as a
larger graph, too, with URI references joining them.

You can see it as a string, though for most manipulation, that makes it
harder to work with, not easier.  Same for a list of lists (which is
ugly if you care about the attribute-versus-node distinction, because we
get a greater-than-1-dimensional tree, though not by much, or we get
ugly NQXML-alike document.child.node.child.note.child.attr[n] syntax,
instead of invoice.customer.name or invoice.items[n].quantity).

> An XML infoset or an XML DOM implementation may be a tree, but an XML document
> is a big string. Or an array of characters. XML itself is about markup syntax
> and Unicode. You can view an XML instance as a bunch of lists, hashes, and
> scalar values, and while mapping it to a tree is handy, mapping it to a sequence
> of events is another option.  Why not map the document to lists of lists, and do
> something LISP-y?

Because that's moving backward, not forward.  A list of lists could be
called a tree, but then, handling even the simplest IDREF->ID case would
be a monstrous task -- something I'd like to see written once in the
general case, then just used.

An XML document is more than just a string -- it's highly structured. 
XML itself is about a meta-data-model, not just it's serialization. I'm
interested in mapping the XML data-model into Ruby's internal data
model: classes.  I don't want another generic XML parser; I want a
system for mapping DTDs/schemas to Ruby.

> > and some sort of map of namespace-tag-class triples should instantiate
> > Invoice, instantiate Customer, instantiate a string as name within
> > customer, instantiate an Array of items, connect Customer to Invoice and
> > connect the Array to Invoice.
> >
> > Any ideas on how to simply express such a map?
> 
> Not offhand, but I would have to believe the Java stuff on XML data-mapping
> would have something useful.

Not really -- it was statically defined for a single DTD.  The map was
hard-coded into the second-tier parser (that took SAX output and
converted that into other classes).  I want something dynamic, so one
can supply a DTD, a mapping, a class library and a document, and get
instances of Ruby objects from the class library.

> By the way, what does this sort of mapping buy you that REXML + XPath
> lacks?   I'm guessing you don't care for this sort of syntax:
> 
>  puts doc["/invoice/customer/name"]

It's not bad, but the objects involved are decided by the parser, not
the programmer. The result of that is a String, but the result of
/invoice/customer is not a kind_of Customer, nor is /invoice/items an
Array.

> Are you looking to manipulate XML-derived data/objects without
> prior knowledge of names and structures?  Or perhaps something
> along the lines of E4X (ECMAScript for XML)?
> http://dev2dev.bea.com/articles/JSchneider_XML.jsp
> 
> e.g.
> 
>   puts invoice.customer.name

That would be great, though having it be schema-aware and very rubyish
is what I want.  In this case, I'd want customer to be an instance of a
Customer class -- I don't want a generic "node" class.  I'd love to have
the result that one works with be completely XML-independent -- that way
it could be serialized with YAML or marshall just as easily.

I'm tackling several problems with this idea -- one is an abstract
interface to serialization, and inside of that, I'd like to have the
XML-based serialization be schema-aware, or at least DTD-aware, and as
transparent as possible.

> Have you looked at XML pull parsers?

Yes -- I like what I see, but I want more random-access.  That could be
in a future implementation, though, since it can be faked by just
pulling the whole thing into core.

> > P.S. If I'm just a really lazy bum who should accept that dealing with
> > XML is hard, tell me so.  I probably won't believe you, though.
> 
> XML is easy.  Certain programming lanaguages and preconceptions make it hard.

That's what I think, too.  XML may be a clumsy beast in some ways, but
that part's already been coded for (Thanks, REXML!).  The data model is
actually somewhat elegant, once you take it all into account.

Ari