W3C home > Mailing lists > Public > www-qa@w3.org > September 2002

Extensions (was: Re: FYI : a new draft of "QA Framework - Specifications Guidelines" published)

From: Lofton Henderson <lofton@rockynet.com>
Date: Fri, 20 Sep 2002 12:56:43 -0600
Message-Id: <5.1.0.14.2.20020920102537.03a97150@rockynet.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 12:13:59 GMT