Final minutes of Apr 19th Teleconf

QA Working Group Teleconference
Monday, 19-April-2004
--
Scribe: Dominique Hazaël-Massieux (W3C)

Attendees:
(PC) Patrick Curran (Sun Microsystems)
(KD) Karl Dubost (W3C, WG co-chair)
(DH) Dominique Hazaël-Massieux (W3C)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(DM) David Marston (invited)

Regrets: 
(DD) Dimitris Dimitriadis (Ontologicon)
(LH) Lofton Henderson (CGMO - WG co-chair)
(VV) Vanitha Venkatraman (Sun Microsystems)
(MC) Martin Chamberlain (Microsoft)

Absent: 
(AT) Andrew Thackrah (Open Group)


Summary of New Action Items: 
 AI PC to send logistics info about the June F2F by 2004-04-23

Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2004Apr/0045.html
Previous Telcon Minutes:
http://lists.w3.org/Archives/Public/www-qa-wg/2004Apr/0053.html


Minutes: 

 * Routine Business

	Next telecon will be about TestLite (PC), and possibly QAH if time
permits.
        Regarding June F2F, PC will send logistics information really
soon now; a quick straw-poll showed that everybody on the call (except
David) plans to attend.
        Following F2F would be in Reading (outside of London in UK) in
October, but needs to get feedback from Andrew to get more details and
start scheduling it.

* SpecLite and Extensions, chaired by Lynne

        The structure and content of the section sent by Lynne [EXT] was
discussed, with 2 main aspects : some of the complexity inherent to DoV
interaction isn't present in the section, and should be presented
through examples ; some of the points given in this section should
belong to a higher level section about optionality and variability,
since they apply more broadly that simply to extensions.
        The WG participants are invited to help with adding examples and
techniques in the Wiki version of the section [W-EXT].

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]
... I sent the Draft Text 
... also sent a ref to the IG on the wiki version of this text [W-EXT]
... calling for ideas, examples, ...
... would like that the WG would participate in this collective effort,
too
... Going into the details:
... 1st, when you're writing a spec, you can't control what an
implementor will do with it
... so the 1st point was to see how you can prepare for this by
controling extensions
... => Design your technology for extensibility
... => Address extensions in the conformance section
... (don't like the titles, but used as placeholders)
... today, talking a bit more about the Principle #2
... principle 2 insists on making clear to the reader on when/how
extensions are allowed
... -> 1st GP: say whether extensions are allowed or not (come from an
old-SpecGL CP)
... -> 2nd GP: prevent extensions from breaking conformance
... -> 3nd GP: say whether extensions affect the conformance claim
... I need help esp. on that one
... Do these 2 high-level principles cover what we need to say?
DM: I'd like to see how we include DoV in this
LR: Leaving them out
DM: I think this is a bit too 1-Dimension
... e.g. an extension could affect modules
KD: maybe it could be handled by the notion of profile? (min profile
being without extensions, etc.)
DM: I'm not necessarily arguing we need another principle
... but this idea of interactions with other things than core should
appear somewhere
LR: point taken
... that's what the last GP is about
... it probably belongs somewhere in this principle
KD: wrt Principle 2, do you mean conformance of products or conformance
of extensions?
LR: I don't know
KD: e.g. in CSS3, conformance is not defined per-module
... I've been discussing with people of the WG, who wanted to implement
only parts of certain modules
... and still claim conformance
... how can you get interoperability in these conditions?
LR: I've kept a very simplistic point of view in this first pass
... obviously need to get a bit further in the complex interactions
... examples would be a good way to get into this complexity
KD: XHTML modularization would be good source, with the way they allow
to defined new "XHTML Mod"-conformant extensions?
... you can have multiple levels of extensions
LR: This may go well under Principle 1
... as a technique to design for extensibility
... Karl, could you write that down, so that it can be used to
illustrate what we're talking about?
... I've tried to keep the principles at a high level, good practice is
ideas about how to achieve the principle
... we're missing success criteria ("if you do this, you'll have
satisified the principle"
)
KD: I volunteer to add a section in the Wiki on this
LR: great! That's why I think using the wiki can be really helpful
... I plan to incorporate a lot of the feedback from the wiki in the doc
... any other comments?
... e.g., Patrick, do you have ideas how extensiblity affects test suite
development?
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?
DM: XSLT has this type of method
LR: in my original outline, there is a section about variability vs
interop
... which would cover David's module cases
... there is a section about flexibility
... which would cover Patrick's optionality
... I'm not proposing to get rid of all the DoVs stuff
... optionality would be handled in a different category
PC: I believe that most of what you say under extensibility would apply
to other kinds of extensiblity
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
DM: still, "not contradicting the spec" is particular to extensions and
is important
LR: right
... I'll keep that in mind when re-organizing the spec
... I'm trying to write discrete sections of the text even though they
are inter-related
... I'll start moving stuff around
... the key point is to identify what it is that we want to require and
suggest
... if you have particular suggestions, this would be helpful
... maybe we should look back at the structure of the old GL/CP
... Please, contribute to the Wiki with examples and techniques
KD: it would be really great if these discussions would happen on the
wiki
DH: let's try to use more the mailing list too ; Lynne's section has
been up since Wednesday but didn't get any comment back
KD: the extensions stuff is really critical to many WG
... would it be worthwhile reviewing extensiblity mechanisms accross
various specs?
LR: definitly
... would be good to look at the various classes (protocols, API,
formatting languages, ...)
... that would be really helpful
KD: I'll do that 
LR: I intend to use extensively the wiki to collect feedback
Lynne will start the discussion about this by asking questions on the WG
mailing list and asking for feedback on the wiki


References
[EXT] SpecLite extensions:
http://lists.w3.org/Archives/Public/www-qa-wg/2004Apr/0040.html
[W-EXT] SpecLite extension in Wiki:
http://esw.w3.org/topic/ExtensionSpeclite
[WEBARCH] Architecture of the WWW, 1st ED
http://www.w3.org/TR/2003/WD-webarch-20031209/
[WEBARCH-EXT] Versioning and Extensibility in WebArch,
http://www.w3.org/TR/2003/WD-webarch-20031209/#ext-version
[KD-TAG] "Extensibility Web Arch / QA Extensions", KD,
http://lists.w3.org/Archives/Public/www-qa/2004Mar/0034.html
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org