- From: Bjoern Hoehrmann <derhoermi@gmx.net>
- Date: Fri, 04 Jun 2004 15:25:08 +0200
- To: Dominique Hazaël-Massieux <dom@w3.org>
- Cc: www-qa-wg@w3.org
* 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