RE: RFC: White Space Handling In XML Parsing

The discussion about "server-based" versus "client-based" tools has popped
up
on this list before.

>>We use XML  for serializing/deserializing Java objects.  We currently
>>use a parser that does not preserve 'formatting' whitespace.
>
>Fine, I guess, but then it's not a conforming XML parser (neither
>validating nor well-formed).
>

That's right. Client applications have different requirements than server
applications, and the W3C has chosen to place a priority on "client-based"
requirements.  But I would think that the length of the discussion on
white-space handling should indicate that there indeed is a community of
users requesting different behavior.

>>Regardless of whether whitespace handling by parsers in the spec or
>>an RFC I think it behooves parser writers to provide both options
>>(whitespace-preserving for editors etc., and non-whitespace-preserving).
>
>I sure don't claim to know what market forces will behoove what behavior,
>but XML parsers must pass on all whitespace.

It seems that there are two broad categories of usage for XML: document
processing, and data processing. White space is important to users concerned
with document processing. It is less important to those concerned with data
processing. At the moment, users concerned with document processing
outnumber (and have more influence than) those concerned with data
processing.

>Anyone adding a switch to
>provide non-compliant behavior will have to make it clear that their
>parser, when operating in this mode, is not an XML parser.

Or perhaps they should make it clear that their implementation extends the
XML standard to meet requirements that the standards body has chosen not to
address. This situation is vaguely similar to earlier HTML standardization
efforts.

>>It would be nice if the mechanism used to switch modes was a
>>public standard though.
>
>A public standard way to request non-compliant behavior from your
>XML parser?  I can't help but think it's odd to try to develop an
>IETF "standard" to contradict a W3C "standard."

How about a modification to the existing standards so that the behavior
required by data processing applications is no longer considered
"non-compliant". I was under the impression that this mailing list was used
as a tool by the W3C to obtain public feedback on the DOM standard--which is
related to some degree to the XML standard. It would think that this is the
appropriate forum to discuss these issues. Is that not the case?

Received on Tuesday, 25 May 1999 01:30:59 UTC