[Prev][Next][Index][Thread]

Re: C.14 Enumerations in attribute declarations?



On Thu, 17 Oct 1996 22:50:07 -0400 David G. Durand said:
>I can't imagine what a non-reportable error even is. If it's an
>error, it should be reported, if it shouldn't be reported, then that
>is prima facie evidence that it should _not_ be an error.

Apologies for my careless phrasing.  'Non-reportable error' is not
expected to be a technical term in the XML spec; what I meant in my
posting by it is an error which is not a reportable error, where
'error' means a violation of the spec the results of which are
typically undefined, and 'reportable error' means an error which a
conforming processor is required to detect and report (unless the
user has turned off error reporting -- to answer David's acute query,
I suspect 'no error reporting' would be the default in a Netscape
implementation of XML, and probably in most browsers).  'Non-reportable
error' does NOT mean 'error which a conforming application is
not *allowed* to detect or report' -- though there might be some
sentiment for introducing such a concept precisely for cases like
this one of enumerated types in attribute values.

Defining double use of a name token to be an error ensures that
SGML parsers can read XML DTDs without modification,
which is clearly a Good Thing.  Not requiring XML parsers to
report it ensures that an XML parser can 'recover' from the error
in an obvious way, which is also (I think) a Good Thing.

We have a stated goal of ensuring that SGML processors should be able to
read XML instances without modification, if the XML instances are
provided with a suitable prolog.  This is not at all the same thing as
agreeing to burden XML processors with every rule, complication,
exception, and restriction in the syntax of SGML prologs, in order to
ensure that the XML prolog itself is suitable for SGML tools.  Any
restriction, complication, or oddity to be built into XML should pass
the same test:  is it essential, is it a good idea, is it worth the
cost?

At the very least, when we adopt rules not on their technical merits but
solely to preserve compatibility with 8879, even in cases where 8879's
rule is now generally conceded to be a Bad Thing, I think the spec
should introduce the feature with the phrase "For compatibility
reasons ... " -- as in "For compatibility reasons, the string '--'
(double hyphen) is not allowed within comments."  WG8 members can then
read the XML spec with a clear idea of where an XML rule was adopted
because it seemed a good one, and where it was adopted solely for
the sake of compatibility with 8879:1986 and will gladly be changed
when the revision sets things right.

-C. M. Sperberg-McQueen


Follow-Ups: