Re: CR issues disposition

Hello Bjoern,

Thanks for this clarification.   We have reopened the issue,

[1] http://www.w3.org/QA/WG/cr-issues#x29 ,

and will have another look next week during F2F.

Regards,
-Lofton

At 03:25 PM 6/4/2004 +0200, Bjoern Hoehrmann wrote:

>* 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 Monday, 7 June 2004 19:16:49 UTC