- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Mon, 01 Sep 2003 06:07:58 +0200
- To: www-qa@w3.org
Hi, If you submit a web page address to the W3C MarkUp Validator, it could happen that the result page tells you that your document is "Valid XHTML 1.0 Strict" and provides a link to the XHTML 1.0 Recommendation. If you follow this link you will encounter a problem: There is no definition of what it means for a document to be identified as "Valid XHTML 1.0 Strict". This is an important issue for web authors and tool developers who care about web standards and I think the current Specification Guidelines draft does not sufficiently address it. There are people in the web authoring commuity who claim that it is obvious what it means for a document to be "Valid XHTML 1.0 Strict"; "Valid" is defined in the XML 1.0 recommendation and "XHTML 1.0 Strict" is the XHTML-1.0-Strict DTD as defined in Appendix A.1 of the XHTML 1.0 Recommendation. I disagree with them. I think it is reasonable to expect that if a document violates requirements of the XHTML 1.0 specification that it cannot be considered a XHTML 1.0 document no matter whether it fullfills the requirements for beeing considered a "valid" XML 1.0 document. Others introduce a notion of "valid but not conforming" which is getting a permathread on mailing lists and newsgroups. I wouldn't mind if they call it "Valid XML 1.0 document but not Strictly Conforming XHTML 1.0 document" but they follow the W3C Validator's lead and call it "Valid XHTML 1.0 Strict but not Strictly Conforming XHTML 1.0". This interpretation hinders me as a tool developer to reuse the term, if my document conformance testing tool is able to test for constraints which are not expressed/expressable in the DTD I can either choose to emit errors *and* identify the document as beeing "valid" which would confuse users as they understand Validity as the absence of errors, or I can identify the document as beeing invalid which would confuse users as my tool considers documents invalid which the in their eyes official and only normative tool, the W3C Validator, considers valid. I could choose different terminology but there are no appropriate defined terms and even if there were they would have worse usability than "valid". The situation will get worse if W3C publishes specifications that define multiple normative schemas. You could get FooML documents that are valid under the XML 1.0 DTD definition of "valid", valid under the W3C XML Schema 1.0 definition of "valid" but still not conforming FooML documents. I would really appreciate if all W3C specifications defining a notion of instance data are explicitly required to identify all programmatically reportable errors, make reporting these a requirement for a specific class of product, define how to identify such software and define how to identify instances which do not have reportable errors. XML 1.0 is a good example that fullfills these requiremements, * reportable errors are identified trough "well-formedness constraints" and "validity constraints" * documents that meet the well-formedness constraints are identified as "Well-formed XML 1.0 documents" * documents that meet the "validity constraints" are identified as "Valid XML 1.0 documents" * software that reports violations of well-formedness constraints is identified as "XML 1.0 processor" * software that reports violations of validity constraints is identified as "Validating XML 1.0 processor" It would be even better if XML 1.0 had conformance requirements (or at least a definition of the term) "XML 1.0 Validator"... This is just a terminology issue but good terminology is **vital** for understanding, discussing, and advertising technology. Beeing involved in both, the XML and web authoring community, I never had to waste my time arguing about what consitutes a well-formed XML document but today no week passes by without a argument about what a valid/conforming/ strictly conforming/whatever HTML/XHTML document is and this is nothing but hair-raising. Thanks.
Received on Monday, 1 September 2003 00:08:25 UTC