From: Aredridel Date: 2003-04-28T04:12:12+09:00 Subject: Re: XML Parsing the Ruby way. On Sat, 2003-04-26 at 21:28, james_b@neurogami.com 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