From: "Sean O'Dell" <sean@...[REMOVE_THE_SPAM]>
Date: 2003-08-28T06:32:26+09:00
Subject: Re: [ANN] QuiXML 0.0.0

Ben Schumacher wrote:
> Sean O'Dell said:
> 
>>It uses only Ruby native data structures to store its XML data
>>internally, so there is no "built-in" way to create XML trees; how they
>>are generated is completely open.
> 
> 
> Sean-
> 
> I'm curious about your decision to differentiate between contents and
> child elements in the tree. While this probably makes the Tree structure
> slightly similar, you end up altering the XML out versus the XML in. So
> that your to_xml will never return the same XML that is passed into it.
> 
> For example,
> 
>   qxml = QuiXML::Tree.new
>   qxml.parse("<a>a  <b att='b'>b</b>b<c>c</c>  \nc</a>")
>   puts qxml.to_xml
> 
> generates the output,
> 
>   <a>a  b
>   c
>     <b att="b">b</b>
>     <c>c</c>
>   </a>
> 
> which obviously alters the structure of the XML. Its probably not a huge
> issue for most projects, but I was just curious if you had considered this
> in your design. One small feature request, however, do you think you could
> add the option to disable the print pretty feature? Maybe make to_xml take
> an optional boolean that defaults to true?
> 
> Anyway... just some comments. I'll probably toy with this more in the future.

Thanks, and please do, I look forward to getting more comments.

My reason for treating content as a single value is because I've only 
ever used XML for data, and never as a formatting stream, like HTML. 
That's basically all there is to it, really.  I used XML a lot for 
configuration files, blocks of data (such as for client accounts) and 
for passing commands/data between remote machines.

I'm open-minded about it though.  Except for formatting streams, such as 
HTML and source XML documents for XSLT to transform into something else 
like PS or what-not, I couldn't think of a reason to NOT combine all of 
an elements data into one content property, so I did that.

How would you like to see it changed?  Give me an idea of what I could 
do different.  Put each scrap of content data in a child element, and 
mark it as data instead of a node?

It would be pretty easy to disable pretty printing, of course, and also 
stripping whitespace when parsing.  Very simple changes.

	Sean O'Dell