- From: Lofton Henderson <lofton@rockynet.com>
- Date: Fri, 20 Sep 2002 12:56:43 -0600
- To: Alex Rousskov <rousskov@measurement-factory.com>
- Cc: www-qa@w3.org
Hi, I want to comment on a couple more bits of the longer earlier dialog. While I think that we probably have some tuning to do on the "extensions" guideline (GL8), I strongly disagree with some of your assertions (as I understand them). We may also have totally different concepts of what extension are (see end)... At 10:49 AM 9/5/02 -0600, Alex Rousskov wrote: >No need to document something covered by other checkpoints. > > > > - Define compliant behavior for every conforming > > > object that the spec is using > > > (no "implicity", good "input") > > > > > > - Define compliant behavior for every non-conforming > > > object that an implementation may encounter > > > (no "implicity", bad "input") [...] > > > "Checkpoint 9.5. If extensions are allowed, register or publish > > > them. [Priority 3]" > > > > > > In general, this is totally unnecessary and introduces too much overhead > > > provided the good/bad input guidelines above are satisfied. 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, at least not beyond requiring that (target) specifications address good and bad input. 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. Somewhere else you mentioned our "N" forms of variability, N<<M (all the possible forms). The N forms that we address include those that (in the opinion of the QAWG) are potentially most pernicious. Further, we think it worthwhile that SpecGL address them because we think that they are not necessarily obvious to all specification writers, not even to all "smart" ones. For example, in one personal experience on a standards committee, we blundered into an unrestricted "extensions" policy without appreciating the potential consequences. It was an interoperability disaster, and took several years of work on profiles and stringent rules for profiles to start to mitigate the damage. (Commercial product vendors who cared to interoperate with the extension-laden content of others had to spend large resources to research, reverse engineer, and "deflavorize" the content.) That example was the graphical standard, CGM. The extensions were legal, valid input. Things like private linetypes, private markers, private geometric objects. All undocumented, all completely mysterious to anyone but the inventors. There is a similar example in SVG. It is legal to define your own graphical elements and attributes, as long as you put them in a distinct namespace and define a DTD snippet for the extension entity -- your privately extended file even validates! A leading graphics-arts illustrator has done just that, including some very fundamental things like compositing model. So now we're starting to occasionally hear about SVG versus "Abc-Systems SVG". Browser wars provide another, non-graphical example -- rampant HTML extensions have made for years of chaos and interoperability failures. "Works best in..." is due in part, at least, to vendor-designed extensions. Okay, so I think that extensions are evil, and that SpecGL ought to address them. And we probably have a fundamental disagreement here. But having said that ("evil"), I'll admit that it need not always the case, and here is where I think we could possibly improve these bits of SpecGL. Different standards have different extension mechanisms, and some have mechanisms that can mitigate interoperability impacts. For example, SVG can provide alternate or conditional ('switch') content, though it is not required. (A strict conformance profile of SVG would do so.) By the nature of CGM, this can't be done. The meaning, behavior, and intended effect of a private line type index, a private font name, etc is implicit and must be defined -- published, or registered. The CGM Rules for Profiles (clause 9 of ISO standard CGM:1999) required of a valid profile that contains extensions: either publish the definition in the profile; or, refer to a registered item in the ISO registry of graphical items. You can see this at http://www.cgmopen.org/technical/registry/, which in turn points at the ISO registry. Summary. Publication/registration of extensions is *really* important for some scenarios (specs), and less critical for others as long as there are mechanisms that can mitigate the extensions (and they are *used*). At 10:49 AM 9/5/02 -0600, Alex Rousskov wrote: >On 3 Sep 2002, Dominique [ISO-8859-1] Hazaël-Massieux wrote: > > > > Have you some examples to provide? Namely examples of an extension > > mechanism without registration that didn't harm interoperability and > > examples of an extension with registration that was too much overhead? > >Note that most existing specs do not conform to SpecGL and do not >satisfy my "provided ..." clause above. > >But if you must have an example for everything, I can say that >extension headers in HTTP/1.1 worked quite well without any >registration (as long as implementations dealing with them were >compliant in that regard). There has recently been an effort to >register/collect known extension headers, but the protocol would be >impossible to use in practice if such registration was mandatory >before anybody can start using those headers. Some past work (in OASIS Conformance TC, I think) elaborated a model of how extensions might evolve (for applicable standards): 1.) truly private extensions; 2.) published extensions; 3.) registered extensions. 4.) fold into revision of standard; The faster you move from #1 to #3, the better it is for interoperability. > > I have at least one counter-example of your assertion: > > - XSLT provides a clearly defined extension mechanism that didn't prove > > useful until some people decided to register a set of them so that you > > get a good enough interoperability (see > > http://www.xml.com/pub/a/2001/02/14/deviant.html and > > http://www.exslt.org/) > >To provide a counter example to an "In general, ..." assertion, you >have to prove that there are no valid examples. One or N counter >examples could be simply exceptions to a general rule. > >I think you are missing the important point behind minor details >though. If you demand that extensions are registered and published, >they are no longer extensions! I distinguish between published and registered. It is perhaps a flaw in SpecGL that we don't do so. But that aside, they are still extensions, IMO, until you reach #4 above. >They essentially become a part of the >ever-evolving spec. However, there may be reasons that someone would stop at #2 -- e.g., limited audience (very few potentially interested other implementors). Or stop at #3 -- e.g., the extensions are only of interest to those of a particular application constituency, for example, the couple dozen registered CGM marker types for the cloud-cover symbols on weather maps. These should probably *not* be put into the more general standard. >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. -Lofton.
Received on Friday, 20 September 2002 14:55:44 UTC