Re: CR issues disposition

* Dominique Hazaël-Massieux wrote:
>In summary, we pretty much agreed with your comments.  The resolutions
>are partially reflected, at least, in recently published (Working Draft)
>components of our redesigned, lightweight QA Framework.  For details and
>specific links, please see the "Resolution" section of each of your five
>issues.
>
>We would appreciate to hear from you, whether you accept our handling of
>your comments.  If you are dissatisfied with any of our responses,
>please provide specifics.

I think I am fine with 27, 28, 30, and 31 for the time beeing and if
there is anything to add from my side I will submit it as feedback on
your new working draft. I am not sure about 29. Since swada.w3.org is
down once again I could not look at the Wiki, but since the document
is called ErrorHandling I am concerned that the working group might
have misunderstood my concern as I perceive error handling as specific
behavior of applications.

My concern however is that, if you want to know what is considered a
Valid XML document you can check that in the XML 1.0 Recommendation

  Definition: An XML document is valid if it has an associated document
  type declaration and if the document complies with the constraints
  expressed in it.

where it is well-defined how to determine whether a document complies
with these constraints or not. If you want to know what a Valid HTML
4.01 document is, you can check the HTML 4.01 Recommendation and find
that it does not define it. This yields in numerous problems, namely
that there is disagreement about the definition. There are at least
three common interpretations:

  a) SGML processors do not report errors when processing the document

  b) the document complies with all machine-testable contraints defined
     in the DTD and the prose of the spcecification

  c) the document complies with all constraints in the specification

I think that neither a) or c) are desirable definitions since a) leaves
too much room for documents that do not comply with the specification to
be considered "valid" and for c) one cannot write software. There is
however disagreement among participants in the W3C MarkUp Validator Team
on this matter, some think a) is the only right definition and I think
we are not going to convince each other. Maybe we could reach consensus
on a different term like "Conforming HTML 4.01 Strict document" but that
would require that we abandon the term "valid" which is undesirable
since the tool is called "Validator" and there term is basically a
brand. We are stuck.

Even if we agreed on b) -- and I do not even think that it is up to us
to reach agreement on this term -- we would have a very hard time to
determine the specific constraints. We would need to draw a line some-
where, for example, even though we know that

  <p style = "color: #xxx">...</p>

has an error that is easily machine-testable, we would probably consider
such a document still valid. Actually, we do not know whether there is
an error here, maybe CSS4 comes along and consideres #xxx a legal value
for the color property. This is however solvable. It is way more
difficult to deal with the various flaws in the HTML 4.01 Recommendation
in this regard, many things are left unclear and contradict each other. 

Such issues could be resolved by the HTML Working Group but even though
they are well aware of many of these issues, they apparently lack the
interest and resources to do so. So do the Validator maintainers...

This is also a legal concern. You are new to web standards and buy a
"HTML Validator" tool. Some time later you find out that this Validator
deliberatly diverges in behavior from the W3C HTML Validator. Can you
get your money back since the product description was so misleading?

And of course a marketing concern. Web standards compliance become more
and more important to customers, it seems reasonable that vendors have
interest in proper terminology to make such claims to advertise their
product.

My point here is that we would not have such problems and many benefits
if specification authors had paid and pay now sufficient attention to
these details, I hope I made this clearer now. What I want the W3C QA
Activity to do is basically everything they can to ensure that future
specifications do not lack such features. With the old SpecGL this would
be a priority 1 requirement for specifications to this effect. I guess
the new SpecGL would provide material so that authors and editors fully
understand these concerns and learn what to do to avoid such problems.
And of course pay specific attention to it in a specifications review.

Glancing over the new working draft I think this is to be covered in
part by section C.1 "Define your terms". I think I can say for the time
beeing that I see progress on this matter and if (a lot of?) detail is
added to this section this does have the potential to satisfy me. I hope
I can make more specific suggestions at some point.

Thanks for your time, Dominique!

Received on Friday, 4 June 2004 09:28:33 UTC