RE: RFC: White Space Handling In XML Parsing

Sorry, I didn't mean to imply that whitespace should ALWAYS be 
tossed just because most applications will not need it.  Clearly
it must be POSSIBLE to preserve all whitespace in the
DOM tree.  As you and Larry pointed out, whitespace
information is critical to some important applications.
I was merely commenting that it would be nice if
the DEFAULT were to toss whitespace nodes in the DOM tree, 
rather than to preserve them, since most applications are
unlikely to need the whitespace nodes.  However, if it is very
easy to tell the parser in a parser-independent
way that it should toss them, then it won't
make much difference either way.

A more important issue, in my opinion, is the question of
whether different parsers should be required to produced the
same DOM tree by default.  I personally think this would be
highly desirable, as it would make it much easier to write
portable code.

David Booth
Bluestone Software, Inc.      +1 609 727 4600   ext. 1740


> -----Original Message-----
> From: Paul Grosso [mailto:pgrosso@arbortext.com]
> Sent: Thursday, May 20, 1999 5:28 PM
> To: www-dom@w3.org
> Subject: RE: RFC: White Space Handling In XML Parsing
> 
> 
> At 16:55 1999 05 20 -0400, Booth, David wrote:
> >I think Larry makes a good case for the value of
> >whitespace preservation in some applications.  
> >
> >Perhaps the key question
> >is how many people will be writing applications such
> >as XML editors that should retain whitespace formatting,
> >versus how many people will be writing other applications
> >that simply need to consume XML, and don't care much
> >about the whitespace formatting the input had.
> 
> No, for the DOM, that is *not* the key question.  Of
> course there are more consuming (browser) applications
> than producing (editor) applications--that is practically
> tautological but irrelevant.
> 
> The DOM has already decided that editor applications are
> key reference applications.  The DOM must allow editors
> to support XML.  Spaces in XML are data and cannot be tossed.
>

Received on Friday, 21 May 1999 15:12:15 UTC