Re: RS/RE, again (sorry)
>>that having all whitespace be significant still seems a reasonable
>>way to go.
>Can you please describe *exactly* what that means?
>At other points, there has been discussion of having a DTD-reading "filter"
>remove the whitespace. Which seems to imply that the former would be *valid*
>as long as the filter is applied before the validation takes place. In this
>case, the grove which is being validated is different from the grove that a
>DTD-less parser would use.
I repeat my viewpoint:
1) The *parser* does not use a DTD, and so creates a pGrove (to use
Elliot's term) in which *all* non-markup charaters occur (lot's
[pGrove -> pGrove]
2) For pure XML *validators* of the pGrove, the following:
would cause an error if LIST couldn't contain #PCDATA.
[pGrove -> validator]
3) For XML *validators* of the pGrove that are built to support
legacy SGML systems, the following:
would not cause an error (ie. "normal" SGML behaviour because
they would perform some transformation of the pGrove).
[pGrove -> validator -> epGrove].
I expect to see most new applications built around (1), and many
others to use (3) to obtain the semantics they desire.
A "parser" is something that tokenises the stream, and checks only
the syntactic constraints imposed by the XML grammar.
A "validator" is something that takes a pGrove, and checks that it
comforms to the constraints imposed by the grammar as defined by a