Final minutes of July 12 teleconf

QA Working Group Teleconference
Monday, 12-July-2004
--
Scribe: (DH) Dominique Hazaël-Massieux (W3C)

Attendees:
(PC) Patrick Curran (Sun Microsystems)
(DD) Dimitris Dimitriadis (Ontologicon)
(KD) Karl Dubost (W3C, WG co-chair)
(DH) Dominique Hazaël-Massieux (W3C)
(LH) Lofton Henderson (CGMO - WG co-chair)
(LR) Lynne Rosenthal (NIST - IG co-chair)
Guest:
(DM) David Marston (IBM Research)

Regrets: 
(MS) Mark Skall (NIST)
(AT) Andrew Thackrah (Open Group)
(VV) Vanitha Venkatraman (Sun Microsystems)

Summary of New Action Items:
AI Karl to update QA Glossary and SpecGL Glossary definition on
   "deprecation" by 2004-07-19
AI Karl to send a summary on deprecation to restart a discussion on
   www-qa by 2004-07-19
AI Dom to make a technical paper out of old SpecGL Profile/Module/level
by 2004-07-31

Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2004Jul/0020.html
Previous Telcon Minutes: http://lists.w3.org/Archives/Public/www-qa-wg/2004Jul/0015.html

Minutes: 
 * Routine business
	RESOLVED: The next teleconf and next F2F dates were confirmed.

   Karl: Andrew has confirmed by mail that we are all set for our F2F
   dates

   dom: should we keep that dates given our new timeline (ending in
   October)

   lofton: it looks unlikely to me that we would publish a good quality
   LC doc by end of October

   karl: we will

   lofton: I think we ought to keep the dates as is
   ... also, other dates would mean that Mark (and/or Lynne) couldn't
   attend

   pc and dimitris are fine with the dates

 * Getting work done
        We need progress on the various sections

   Karl: will do mine this week
   ... and will start putting altogether my sections in an editorial
   draft
   ... integrating the comments that have been made
   ... please don't wait to much before sending your proposals
   ... when you write stuff, that makes up for contreversies, which help
   making the discussions alive :)


 * helping XKMS WG
	RESOLVED: PC agreed to participate in an XKMS call, Karl will make the contacts.

   Karl: the XKMS WG is setting up a TS
   ... they need expertise on how to proceed
   ... and would like to have someone coming to their call

   PC: if you can send me a private mail, I'll take care of that
   ... sorry I dropped the ball on it

* Test Case License issue
	RESOLVED: LH will integrate AB's recommendation; PC will review the IPR
FAQ once it's available

   LH: I don't think there is an issue anymore FWIW
   ... what the AB is recommending is not that far from what we said
   ... I was put off by the fact that this solution came out of nowhere
   ... but what they resolve doesn't look objectionable
   ... and I'll integrate this in the next version of the QAH

   Karl: it's not coming from nowhere
   ... all the past work in this issue has been worthwhile

   LH: what I meant is that it came out of a group without visibility for
   us and the world
   ... we won't know how they came to that decision

   Karl: I've seen a FAQ is being in written
   ... who? date?

   dom: Ian Jacobs is in charge
   ... probably not before August
   karl: is someone willing to review it once it's available?

   lofton: I can do it, but I think PC would be a better candidate

   PC: I'll do it, unless I can't at that time

   LH: so we should remove the old references?

   DHM: indeed

* Deprecation and obsolete features
   RESOLVED: Karl will update the glossaries with Lynne's definition of
deprecation, and will restart the discussion on the various open
questions around this topic

   Karl: HTML 4 defines deprecation fairly well
   ... haven't seen other definitions elsewhere
   ... Lynne pointed me to a misconception I had made in my first def
   ... that obsoleting was only when it was replaced by a new feature
   ... there is also a possibility that the feature is simply being
   dropped
   ... Also, open question on deprecation/obsolete/error handling?

   Dave: also, Al's question about "pre-deprecation"

   karl: also, deprecation and versioning can create difficult problems
   to solve
   ... e.g. deprecated properties in CSS validator

   dom: sounds interesting to tackle
   ... like the definition proposed in
   http://lists.w3.org/Archives/Public/www-qa/2004Jul/0000
   ... how should we proceed?

   karl: I'll try to summarize my thought on this and send it to www-qa
  ACTION: Karl to update QA Glossary and SpecGL Glossary definition on
   "deprecation" by 2004-07-19

   ACTION: Karl to send a summary on deprecation to restart a discussion on
   www-qa- by 2004-07-19

   LH: I had a comment about not mixing definitions and good practices
   ... the line wasn't always very clear in the mail thread
   ... last defintion from Lynne looked good to me

   Karl: I'll try to send the def on the ml, and if you still have issues
   with it, let me know

* Profiles, modules and levels in SpecGL
	RESOLVED: profiles/modules/levels from old SpecGL will be published as
a technical note
	RESOLVED: Lynne will send proposal about GP and principles for section
on dividing a technology

   Karl: Lynne proposed to take them out of old SpecGL and include them
   in SpecGL lite

   LR: I read over the concept section in the older SpecGL
   ... it reads very well, with very few changes
   ... so, can we just take it out and make it into a technical note?
   ... I think it can stands on its own
   ... if there are objections to that, we need to put it into an
   appendix of SpecLit
   ... but I think the stand-alone note would be better

   DM: How would SpecLite direct people that DoV must be treated according to 
certain principles?

   LR: I'm only talking about profiles/modules/levels
   ... the section that Dom wrote with illustrations
   ... in SpecGL, I'm in the process of thinking about the principles
   ... for subdividing technologies
   ... I'd like to make reference to this external note

   KD: I had an old AI to write a summary about P/M/L
   ... I'm willing to participate in it
   ... anybody against this?

   dom: sounds like a good idea
   ... FWIW, what we're doing is looking more and more like what the TAG
   is doing
   ... with their findings completing the main ArchDoc

   Karl: who's interested in doing this?
   Dom: I can lead it

   Karl: and Lynne, Karl, and DM will help

   LR: only address Profiles/modules/levels

   Karl: there are other topics that could benefit from this approach,
   e.g. DoV
   ... but remember that the priorities is to write SpecGL
   ... any other topic?

   LR: I'm thinking about writing the section on the "subdivide
   technology" in SpecLit
   ... would like to get feedback on how to proceed
   ... 1st thing I would like to do is to say that it's a good practice
   to divide your technology in such or such a way
   ... but then if someone follows this GP, there is a principle that you
   do certain things
   ... is that OK? Since that's conditional

   DM: I think it makes sense
   ... but what is the GP you're thinking? that if you subdivide, it
   should be a profile, or a module or a level?
   LR: the GP would probably more generic "think to subdivide your
   technology", and then p/m/l is techniques

   DM: I think subdiving is bad practice
   ... if you can do it uniform, do so
   ... but if you can't and have to subdivide, do it with profiles or
   modules or levels

   LR: so you don't think it's a good idea to subdivide?

   DM: right

   KD: I would not say it's a bad practice
   ... but that's a practice that should be used very carefully
   ... once you start to subdivide, you make it easier for each small
   part
   ... but you have to take care of all the new interoperations that
   appear
   ... it may be easier for developer, but then you may have to do
   profiles to bound all the modules together
   ... and thus a more complicated conformance section
   LR: that's giving me some ideas

   LH: it looks to me that what you're looking for is a net gain in
   interop
   ... that should be the criteria
   ... by default, subdividing is bad for interop
   ... but in some cases (huge spec as SVG), you have to subdivide if you
   want it to be implemented interoperably

   LR: so, 1st I would introduce criteria to decide whether to subdivide
   or not, with pros and cons
   ... people that don't subdivide can skip the section

   LH: you could integrate it into a GP or a principle
   ... by targetting the "net gain in interop" approach
   ... as in risk analysis in economy

   LR: I don't think I need a GP for that

   LH: the GP could be "subdivide if it's going to improve interop"

   DM: but subdividing is usually just for political acceptance
   LR: I don't think I need a GP for that

   LH: but in the end, that targets interoperability

   LR: so first, a GP about pros and cons for subdiving
   ... if you subdivide, further requirements
   ... otherwise, skip the section
   ... I'll have a first stab at it and will look for your input

   KD: let's adjourn; don't forget to send your participations to SpecGl
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org