- From: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Date: Thu, 12 Dec 1996 15:13:34 -0500
- To: w3c-sgml-wg@w3.org
At 02:09 PM 12/12/96 EST, lee@sq.com wrote: >Paul Prescod said: >> But existing DSSSL scripts will break, because they would not expect these >> pseudo-elements to be significant. > >Well, both of the two existing DSSSL style sheets in the world :-) are >written for SGML DTDs that are not directly XML compatible, so that's >not a problem. It isn't really the legacy issue I'm worried about. It is requiring every new DSSSL script to include code to detect and destroy whitespace that the author thought (reasonably) was only for pretty-printing. It is even more than that...it is the idea of having pretty-printing whitespace be something that is handled by the application *at all*. That's out of whack with most people's understanding of a parser's job. C++ parsers don't return "whitespace nodes" between tokens that the C++ "back end" must detect and delete. >Furthermore, if you use DSSSL with an SGML parser, you'll get SGML >whitespace rules. Since we haven't discussed the use of DSSSL with XML, >it could do anything it liked... I don't really understand that point. >> Every application that is currently based on an SGML parser will >> get a different parse tree from an XML parser. > >Yes. And that's fine. Well, that's the XML status quo. I hoped that we could do better. I think it will be rather annoying to have to know when I code my style sheets whether the application uses an XML parser or an SGML parser. I might just instruct authors to avoid whitespace between elements altogether, since it will not be reliably interpreted (which, I guess, is what some people want). Paul Prescod
Received on Thursday, 12 December 1996 15:10:51 UTC