Re: RS/RE, again (sorry)

> 
> >It's becoming a little clearer. I'm starting to wonder if we're talking 
> >apples and oranges.  Your proposal seems to define an application
> >architecture (what components say what to what). But I don't understand
> >how that translates into a *language* (what is valid, invalid, and what
> >constructs mean).
> 
> Very simple. The XML *language* as I look at it, is completely
> seperate from the language defined in a DTD. In other words, I am
> concerned primarily with the meta-language language definition, while
> you are primairly concerned with the language defined *using* the
> meta-language, which I leave to the "validator".

Fine. So in your opinion, should the "validator" be part of the XML 
specification or not? If so, does it really matter what the "parser" returns?
All the user cares about is what is valid or not. If not, then it will be
entirely valid (excuse the pun) for me to make a "validator" that says that 
"foo" is an appropriate separator character in element content so that this:

<ULIST>foo<UITEM>foo<P>foo</P>bar</UITEM>bar<UITEM>baz</UITEM></ULIST>

is valid in element content. Or, I could go even farther and decleare that 
according to my applications' "validation scheme", all content everywhere
is valid.

Should we specify a single standardized validation scheme or not? If we do,
what do you propose it should say about whitespace? If we do not, how can we
claim to be even vaguly SGML compatible? As you mentioned in your last 
message, SGML's validation scheme would be just one of an infinite number
of equally "valid" schemes.

 Paul Prescod

Received on Wednesday, 18 December 1996 11:36:26 UTC