Re: Mixed vs. element content (Was Re: RS/RE, again (sorry))
Subject: Re: Mixed vs. element content (Was Re: RS/RE, again (sorry))
From: Paul Prescod <firstname.lastname@example.org>
Date: Tue, 17 Dec 1996 21:17:36 -0500
From email@example.com Tue Dec 17 21: 14:34 1996
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
At 08:45 PM 12/17/96 -0500, Gavin Nicol wrote:
>I wonder how HyTime can break when used with XML when there is no
>current practise in the field? Same for DSSSL, or whatever other
>processor you have.
Since XML is SGML (theoretically) we do have current practise.
>So far, we have been trying like mad to make XML a pure subset of
>SGML, to the extent of using hairy features of SGML to get it to
>do what we want. To me, this means that unless *all* SGML systems
>we care aboput are capable of supporting the features that XML
>requires, the issue of whitespace-handling conformance is a non-issue,
>as you're going to have to preprocess an XML document to get it
>through your SGML system anyway.
SGML systems can be updated. It is better that they be updated to support
optional SGML features than proprietary W3C-XML features.
>Why can't you have the preprocessor perform whitespace normalisation as well?
Because SGML has the whitespace handling behaviour that we want (other than
RS/RE). It allows insignificant whitespace in places where it is obvious to
author and parser that they could not be data. It would make no sense for us
to convert from a system that is less text-editor-friendly to a system that
is more. If any conversion is involved it should be downconversion from
SGML, using its reasonable whitespace handling rules (barring RS/RE) to XML
(as was originally envisioned by many participants).
Anyhow, we can all get what we want. If we use a simple syntax for
triggering whitespace removal, then those who think that All Whitespace
Should Be Significant can just choose not to ever use that syntax. Parser
writers still have to implement it, but it would be fairly trivial.