[jdom-interest] XMLOutputter and newlines afterdeclaration/doctype

[James Todd]

re xml readibility, adding tuples to your flat example should highlight 
the benefits
of sticking with xml.

as to readibility i can add that before tomcat had server.xml it used a 
relatively
flat/simple prop file. the number of "how do i" type tomcat questions 
virtually
disappeared upon moving to xml. further, folks have added interesting 
config extensions
to server.xml that would likely be very unintuitive mapped to prop files.

lastly, xml structures and associated parsing logic are much more 
resilient to
extensions and tweaks then flat alternatives.

if folks don't like the verbosity of xml they can, at the cost of 
readibility, obfuscate
the element/attributes names down to meaningless albeit short tokens.

- james

Ingo Struck wrote:

>Hi all...
>
>I tracked that discussion and want to add some words too:
>
>  
>
>>Vadim.Strizhevsky at morganstanley.com wrote:
>>    
>>
>>>Yes, it is about XML, and should be. Therefore you should let me
>>>output XML the way I _want_ to.
>>>      
>>>
>I guess, that you will, like me and some of my colleagues did in the past
>two years, discover that this (at least your particular problem) really is
>*not* about XML, as well as most of your day-life problems. :o)
>
>  
>
>>>Why do you all feel that it is such a big or unusual thing to ask for,
>>>to be able to produce XML with no white space or newlines?
>>>      
>>>
>We made extensive - and to be honest bitter - experiences with the use
>of multi-xml-doc / db-like structures. If you want a good advice, try to use
>something that suits your problem.
>
>  
>
>>>2) performance.
>>>      
>>>
>>You've done the testing necessary to prove that XML parsing is a problem?
>>    
>>
>
>  
>
>>Yes. XML parsing and XMLoutputer is number 1 performance bottlenecks. I've
>>done some mods to XMLOuttpuer to increase performance even furhter. But
>>this for a separate mail.
>>    
>>
>I highly agree. 
>Of course that is *always* the main performance problem.
>It is not an implementation specific problem, but has much to do with
>maladjustment to hardware / operating system structures the XML approach
>implies. And you are right, this is a whole discussion thread, that should be
>discussed elsewhere.
>
>  
>
>>Without getting into a flame war here, I agree with Vadim on this. This
>>whole thing seems to be turning into a debate on how he's using JDOM.
>>That's fine, if someone feels the missionary compulsion to go out and
>>convert the heathens to the One True Religion, but doesn't change the
>>point that his basic request seems reasonable and appropriate.
>>    
>>
>The words of a sage...
>Maybe the question here should rather be whether to use XML everywhere.
>It is really not for the purpose of readability, if a configuration entry of a 
>well-known web-app server looks like:
>
><servlet>
>    <servlet-name>init</servlet-name>
>    <servlet-class>org.foo.bar.InitServlet</servlet-class>
>    <init-param>
>      <param-name>debug</param-name>
>      <param-value>2</param-value>
>    </init-param>
>    <load-on-startup>1</load-on-startup>
> </servlet>
>
>where it could look like:
>
>servlet/init/class = org.foo.bar.InitServlet
>servlet/init/debug = 2
>servlet/init/load-on-startup = 1
>
>I think it is comprehensible that the latter is much easier to read, both for
>machine and human readers. :o)
>
><flames value="on" /> respectively flames/on...
>
>Kind regards
>
>Ingo
>_______________________________________________
>To control your jdom-interest membership:
>http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com
>  
>