Hi Sean.

It sounds to me as though you would get much better mileage from YAML 
for what you are describing. As long as you don't need to send the XML 
onto any other non-Ruby systems, it's a very lightweight way of 
marshalling, storing hashes and arrays, all that stuff. I've only 
recently come across YAML but the more I play with it, the more I'm 
liking it.

You can't do xpath stuff with it, but then you don't need to - it loads 
as first-class Ruby objects.

Cheers,
Dan



Sean O'Dell wrote:

> Gavin Sinclair wrote:
>
>> On Wednesday, August 27, 2003, 5:50:09 PM, Sean wrote [snipped]:
>>
>>
>>> I've been a big fan of Sean Russell's REXML library for awhile now, 
>>> but an internal project in which I embedded the Ruby interpreter 
>>> required certain features in an XML library I couldn't quite get out 
>>> of any one of the existing API's out there, so I wrote QuiXML.
>>
>>
>>
>> I'm curious, what features did you need that weren't already provided?
>>
>> Gavin
>
>
> Well, quite a few things I couldn't get in a single library.
>
> One was marshaling (transmutation: not really marshaling); I was 
> reading/writing a lot of XML, and I wanted some of it to come and go 
> as Ruby objects.  I had code that was performing that task for me 
> "as-needed" but it got to be a REAL pain after awhile, and I wanted to 
> do something a little more out-of-the-way.
>
> Another was native Ruby data types.  I wanted to be able to generate 
> an XML data tree using only Hashes and Arrays, because the XML was 
> going to and from some other code and I didn't want to stop and write 
> abstraction layers.  A happy medium for me was generating trees using 
> only Ruby data types, and then passing them off to QuiXML to be 
> written, performing, of course, marshaling as it went.  Even though 
> it's not a true abstraction layer for the other code, having it all as 
> native Ruby containers means I can rip out QuiXML whenever I want; 
> it's very easy to generate XML output from a set of native containers 
> with a known structure.
>
> Also, I just *like* creating my trees as native Ruby data types, 
> rather than depending on the library itself to perform that task; it 
> just feels more flexible that way.  I feel sort of "tied up" with the 
> XML library with commands like "add_element."
>
> Another thing was XPath; it works well most of the time, but sometimes 
> I feel mired with it.  Since my QuiXML trees often contain real Ruby 
> objects, rather than strings, it made more sense to produce an 
> addressing scheme that made use of the "case-equality" method that 
> many built-in objects have (String, Regex, Range, Date, etc.).  The 
> way QuiXML's element path addressing works, you can find elements 
> using regular expressions, numerical ranges or even look up specific 
> dates or ranges.  I've just been a lot happier with it; it feels more 
> "Ruby" to me.
>
> Also, it had to be in C.  I eat through a lot of XML, and using C with 
> the expat library just makes it blazingly fast.
>
> Mmm... automatic encoding/decoding of special characters like <, >, ', 
> " and & too.
>
> Ah, and last but not least: I just feel a lot more productive in it.  
> =)  I released it because I thought perhaps like-minded folks might 
> appreciate it.  =)
>
>     Sean O'Dell
>
>
>
-- 
Dan North
http://www.thoughtworks.com