FPWD SpecLite Scope [was Re: Draft minutes of Apr 19th Teleconf]

In February and at TP2004 f2f, we said these things about QAF-lite:

** refactorization, simplification, and prioritization of CR QAF stuff;
** should be quick because we've already resolved the issues.

It is certainly going to be a challenge to publish QAF-lite before the 
moratorium, even with these constraints.

Looking at the minutes, I'm afraid that we might straying -- trying for too 
much (esp. w/ 4/29 looming a few days away).  Perhaps, since I wasn't 
there, I'm misunderstanding what way forward is being proposed (in the 
minuted discussion).

In my view, a simplification along the lines of [1] suffices for our goals 
of this first publication ([1] is just a "for example" of where we should 
go in rearranging the new stuff).

Further comments in-line...

At 06:12 PM 4/19/2004 +0200, Dominique Hazaël-Massieux wrote:

>QA Working Group Teleconference
>Monday, 19-April-2004
>[...]
>
>LR: to put details in the outline, I started to work on the "extensions"
>section [EXT]
>... partly, because this overlapped [WEBARCH-EXT] with the WebArch
>document  [WEBARCH]
>... and this gives us an opportunity to interact with the TAG
>... and check where we may possibly be in contradiction
>... Karl wrote to them about this [KD-TAG]

It is good that we start the interaction.  But I think it's a mistake to 
try before FPWD to find accommodation with what WebArch has 
written.  Especially since I disagree with some of it.

I can't tell whether the intention Monday was to search for accommodation 
now.  For this FPWD, I think it is perfectly okay to green-style-flag 
issues that are not resolved yet, and this could (should) be one of them.

>[...]
>... => Design your technology for extensibility

Here is an example of something we didn't say in CR SpecGL.  I almost agree 
with it, but not quite.  (I would agree that you have to address and 
consider extensibility when you design the technology.  I would not agree 
that you have to design extensibility into the technology.)

FWIW, I won't object to this going into FPWD, because of the schedule.  But 
I may raise it as an issue after publication.

Similarly for the ideas in this thread...

>[...]
>PC: we would not test for extensions since they are not specified
>... we would test only for optional behaviors
>... Why are we separating this special kind of optionality
>(extensilbity) from other kind of extensibbility?
>KD: the fact is extensibility is one of the most used kind of
>optionality
>... I've heard a CSS WG participant wishing for the equivalient of the
>.hasFeature() method as defined in the DOM specs
>PC: are you talking about unspecified behavior or about optional
>behavior?
>[...]
>PC: I believe that most of what you say under extensibility would apply
>to other kinds of extensiblity  [LH:  the latter should be "optionality"]
>LR: good point
>PC: could the principles be generalized to all forms of variability?
>LR: that may be the case
>DM: I'm hearing two different top-down approaches
>LR: PC raises a good point ; the only extensibility-specific point is
>the design of a hook to allow extensions
>... all the other good practices can be applied to a higer level
>... so that it applies to other DoV

This is an argument that should happen *after* publication.  I.e., we 
should not try to define a new taxonomy of variability stuff before 
FPWD.  We spent a *long* time sorting these questions.  "Optionality" isn't 
even one of our current DoV.  "Discretionary ..." is one (and comes in 3 
well-defined flavors).

IMO, and in my experience as an implementor of standards, there are good 
reasons to separate Extensibility for special attention.

There are some intriguing ideas in this thread, and they shouldn't be 
lost.  But they are definitely for SPWD (after Santa Clara), not for FPWD 
(this week!).

Regards,
-Lofton.

[1] http://lists.w3.org/Archives/Public/www-qa-wg/2004Mar/0028.html

Received on Saturday, 24 April 2004 16:29:26 UTC