- From: Jeff Mackay <jmackay@vtopia.com>
- Date: Tue, 25 May 1999 00:35:31 -0500
- To: <www-dom@w3.org>
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