- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Thu, 12 Dec 1996 09:54:26 -0500
- To: gtn@ebt.com (Gavin Nicol), eve@doctools.com
- Cc: w3c-sgml-wg@w3.org
At 09:25 AM 12/12/96 -0500, Gavin Nicol wrote: >You can handle this with a rule saying that all PCDATA psuedo-elements >that are direct descendant of <list> need not be displayed. You should >be able to do this with DSSSL, I believe. But existing DSSSL scripts will break, because they would not expect these pseudo-elements to be significant. The problem is that you get a different parse tree if you use an XML parser (which doesn't discard any whitespace), or an SGML parser (which must). And of course, DSSSL scripts are only the beginning. Every application that is currently based on an SGML parser will get a different parse tree from an XML parser. For some (mostly browsers) it will not be a big deal. For others, it will be. The current XML specification does the same thing, but it divides the parser world into two categoreies: validating parsers, which will produce 8879 parse trees, and non-validating parsers, which may not. Presumably you use non-validating parsers for browsers, and hard-coded apps, where it doesn't matter, and validating parsers for other applications. Your proposal, though, divides the world up into thousands of different categories: applications which keep all whitespace, applications which use 8879's rules, and applications which use totally proprietary whitespace elimination rules. In practice, that means that we'll all end up using Microsoft and Netscape's whitespace elimination rules (whatever they might end up being). No thanks, I'd rather provide a mechanism for having totally meaningless whitespace, just as we have a mechanism for totally meaningless <!-- comments -->. Just as comments *may not* appear in the text of a conforming browser's parse tree, the spaces between list items should be defined to disappear. I have suggested that perhaps we should use STAGC syntax to make this easily possible. Paul Prescod
Received on Thursday, 12 December 1996 09:51:45 UTC