- From: Michael Sperberg-McQueen <U35395@UICVM.CC.UIC.EDU>
- Date: Fri, 18 Oct 96 10:07:47 CDT
- To: W3C SGML Working Group <w3c-sgml-wg@w3.org>
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
Received on Friday, 18 October 1996 11:29:12 UTC