Re: [qaframe-spec] conformance tools vs. broken specs

At 12:07 AM 2003-09-01, Bjoern Hoehrmann wrote:

>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.

For modular and multi-schema specifications there is complexity
that can't necessary be laid out in the manner you recommend below.

At least if one uses EARL to spell out the conformance claims, one can be
surgically precise that the 'valid' in the clause "Valid XHTML 1.0 Strict"
is valid-to-DTD as defined in XML 1.0 and the XHTML 1.0 Strict is a
reference to the DTD, not the specification.

And if you have a site conformance policies page with the EARL details in it
you can be terse in each HTML instance in citing that policy.

Given that the most-used specifications lay different groundwork for
compliance claims, and that migration off these to the future specifications
that would make the compliance-tool-integrator's job easier is not
progressing rapidly, it would seem that the prudent approach is to make sure
that we are getting the practice of _precise conformance description_ in the
field before we try to converge on _better consolidated conformance
prescription_.

At least if all the tools we rely on for orthodoxy enforcement in our content
development chains all offered EARL output, then one could mix and match and
compose the results correctly.

Al


>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 Tuesday, 2 September 2003 09:50:53 UTC