- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Fri, 20 Sep 2002 14:09:50 -0600 (MDT)
- To: Lofton Henderson <lofton@rockynet.com>
- cc: www-qa@w3.org
On Fri, 20 Sep 2002, Lofton Henderson wrote: > Major disagreement here. As I understand, you're saying that it is > not necessary for SpecGL to enumerate or state checkpoints on any of > the individual dimensions It is not necessary for SpecGL to enumerate or state checkpoints on any of the individual dimensions iff those checkpoints are sub-cases of other, more general, checkpoints. > First, a general observation. In SpecGL we are addressing (a > half-dozen or so) specific "dimensions", such as Extensions, because > in the collective experience of QAWG members, these have repeatedly > been associated with serious interoperability problems. Yes, I understand that. I believe that Checkpoint 9.5 above does not, in general, solve the Extension problem you are trying to solve (while requiring a lot of overhead to comply). Registering an extension may or may not solve interoperability problem, depending on the spec and on the registry. We need to look deeper. [ lots of good stuff snipped for the above reason ] > >By its very definition, extension is something > >that can be added without being known to others and still work. That's > >what important. > > Bingo! You and I apparently have different concepts about what extensions > are. In the examples that I'm quoting, if the extension is not known to > others, in fact the content does NOT work. SpecGL should define extension before introducing checkpoints that cover them. For example, we could agree that "extension" is something that can be added without others knowing anything about it, except for the fact that it is an extension. Then we could proceed with defining a "good extension mechanism". What SpecGL is doing now is providing an implicit instruction for authors how to make some extension work: "register your extensions and you are covered!". What SpecGL should be doing is requiring that extension mechanisms maintain interoperability among parties that MAY NOT be aware of each extension definition. SpecGL should address the _core_ of the problem instead of demanding a specific solution to one of its known side-effects. I am skipping lots of smaller problems with "extension registries" to keep the thread shorter. SpecGL already tries to define a "good registry", but there are many things the current attempt does not cover. My point is that SpecGL should not digress to a specific and imperfect solution; it should address the core problem (interoperability in the presence of extensions). Alex. -- | HTTP performance - Web Polygraph benchmark www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite | all of the above - PolyBox appliance
Received on Friday, 20 September 2002 16:09:57 UTC