QA Working Group Teleconf

16 May 2005


See also: IRC log


Dom, Karl, Richard, Patrick, Tim_Boland, Lofton, Dimitris, MSkall, DaveMarston


formal agreement to request SpecGL transition to PR

karl: any disagreement wrt to requesting transition to PR
... ?

tim: how do we look in terms of implementation?

karl: the current implementation report is good enough
... so unless anybody wants to go back to making more spec reviews to check...

dom: the schedule is only set by ourselves, so if you want moer time for gathering experiences, that's acceptable

tim: I trust the W3C process will assess whether we have enough implementation
... we could always gather more reports, but if you feel what we have now is sufficient, that's fine with me

mark: difficult to guess whether this is good enough

lofton: I think we should go to the teleconf with the attitude that we have enough implementation reports
... in the few places where implementation is thin, I think we can argue that these are useful guidelines, independently of whether they were already in use
... SpecGL is different from CSS or DOM

mark: plus, we have conversed with people, had many comments, have worked hard on the issues, have rewritten the doc

karl: xml:id plays in our favour, too
... their ICS went from very bad to SpecGL compliant through discussions
... it shows that this can be achieved

dimitris: reading the implementation report, it's patent that SPecGl availability has actually improved the specifications over time

tim: do all the issues have to be resolved?

dom: all our issues are resolved
... although some commenters disagree with our resolutions
... still trying to negotiate with Ian
... but even if there is disagreement, we can go to PR

karl: I've replied to Ian with more details this morning
... hasn't reached the archives yet

RESOLUTION: QA WG requests transition of SpecGL to PR

Test FAQ Published

karl: Test FAQ was published last week
... bravo to Patrick and others
... it was announced on the chairs mailing list

Tim: I've forwarded the announcement to WG I'm involved in

Karl: It's a good thing to promote it insided W3C WG
... but promoting it outside W3C is also nice
... if you have opportunities, please do

dom: any feedback yet?

patrick: no feedback at this time

tim: what's the process/schedule to integrated feedback?

karl: no specific schedule; we update it when we receive feedback that we want to incorporate

patrick: feedback address given in doc is www-qa-wg

karl: we can republish and make additions to the document when we need

mark: any other specific ideas to promote it? Conferences, this kind of opportunities coming up?

karl: always good to do it at conferences
... another good way is to introduce it in small bits
... e.g. addressing a question in a mailing list with a pointer to the document
... can help attract readers

dave: the testing faq has already been publicized to the XQuery Test TF
... don't know how many WGs have test moderators or task force
... there could be a cross-WG mailing lists to contact testing coordinators

karl: xmlspec could also be used as a link to the FAQ

tim: the WCAG techniques tf is working on testing issues
... I can see the utility of the test faq in that context

patrick: I like the idea to point to specific answers and questions

Dublin hotel

patrick: somebody looking it up for me
... it's coming

Variability in Specification

karl: Dave has a proposal to reorganise the document

DaveM: should there be a mention of some of these dimensions by citation over to SpecGL where they're already fully explained or should there be a repeat of the material? or another approach?

dom: if we have nothing new to say about extensibility in ViS, I suggest dropping the section
... and linking to SpecGl

Dave: so indeed extensibility could go away
... except for interrelationships between DoV

karl: would it be possible to create templates to develop each of these DoV
... with questions to be addressed for each DoV
... ? this could help people to write content
... we could then use the wiki to get content

tim: is ViS considered a specification?

lofton: the SOTD says it's destined to be a WG Note

mark: not clear to me how do we envision ViS to be used
... don't know how we can make decisions like this without having this vision

dave: when ViS was started, the idea was to collect advanced topics that wouldn't fit in the spirit of SpecGL

mark: so, read this document to learn more about the issues regarding variability

dave: this doesn't imply whether this should go rec-track or not

mark: if that's the model, I don't know why we wouldn't talk about extensions
... the extensions are important enough to be there

dom: but we don't have anything new to that

mark: but even a regurgitation of what's in SpecGL could fit
... it would be too bad if it wasn't there

karl: my vision of ViS is a kind of encyclopedia vs SpecGL a technical framework
... what are the big/high-level issues wrt developing a specification

dave: so, is there agreement that ViS is dependent of SpecGL
... and thus would assume that the reader has read SpecGL first

karl: do we want to require this?

dave: we could avoid it, but that would need more work

dom: if we can avoid it, I'd rather, but that's only a nice thing to have IMO
... please note that we don't have many cycles to make progress on this doc, so we need to be practical on how it goes forward

dave: here is a proposal
... we keep a section on each DoV, with a small paragraph e.g. for extensions

lofton: I wonder why each section doesn't link to the matching SpecGL section?
... eg profile/module/level don't link back to SpecGL

dave: some DoV are so little developed in SpecGL (e.g PLM) while others are much more expanded (e.g. extensibility)

dom: no link back is mostly an editorial oversight, I think

lofton: so this link back could be the basis for the placeholders

dave: so ViS would address all the DoV
... since there are consensus on that, we can go on to what should be the sequences of chapters
... currently, the sequencing in ViS is CoP, Profile/Modules/levels, extensibility, optional features
... extensibility should be last wrt to ordering of DoV

lofton: deprecated features shouldn't be taken as part of optional features

dave: how do people feel having several DoV in just one chapter?

tim: what would the title be?

dave: I don't have a proposal off the top of my head
... it may be better to have deprecation and optional features separated

dom: I think it would be clearer

dave: ok; but then why having profiles/modules/level bound together

dom: profiles/modules/levels were bound because they were all subdivisions
... but I don't think we would lose much by separating them

dave: current spec would flow well with this
... except for umbrella specs
... that we could move to modules
... let's see when we get back to discussing umbrella specs

karl: how would like to proceed to edit the different parts and get contributions?

dave: I think we should concentrate on getting a document published in a later version
... with the placeholders of extensions and deprecations
... and we would split the PML section into 3... we would need to move the intro of PML somewhere else
... would need your help, karl, to do the technical editing

karl: what about contributions? who should contribute?

dave: if someone wants to write a quick paragraph on extensibility and deprecations, good
... but otherwise, I'll do it

karl: what schedule to envision for this?
... also, if you can consider creating a template for the various parts, this would be really useful

dave: I think this would be for another pass to the document
... I need a week to do the transformations we mentioned before
... if everybody agrees, it may be ready to go as early as after next week teleconf
... also, is there any feedback on my proposed rewrite?

karl: please comment on the mailing list

Umbrella Specification and Profiles

Karl: Tim asked whether profiles were umbrella specifications or not
... I think not, although I'm not necessarily objecting to it
... Dom thought they were
... but wondered what we wanted to do with this concept

Tim: what about specifications that may point to several technologies? how do we defined technology?

karl: as CDF - compound document format?

tim: there is a tendency to bind technologies together

karl: it's very rare that specifications don't rely on other technologies
... what do you expect from umbrella specs?

dom: I guess my question was really why do we define this concept if we don't say anything about it?

karl: origin of this is "how to move forward a technology defined in many pieces?"

dave: there are already wg producing umbrella specifications

dom: the fact they exist isn't enough
... again, there is nothing said except the definition about umbrella specs

karl: another related topic is whether defining a module without an umbrella spec is good or not
... the example came because of CSS3
... we probably need to discuss it more on the mailing list

<scribe> ACTION: karl to give a better outline of the issue and to move forward the discussion on umbrella specs [recorded in http://www.w3.org/2005/05/16-qa-minutes.html#action01]

Taxonomy of tests

dom: was developed by Daniel back in 2001
... lofton asked whether we still agree with this classification
... and patrick wonders whether and how this should be integrated in the FAQ

patrick: this addresses the "testing approaches" question
... I'll send specific suggestions/questions to www-qa-wg

dave: I'll have comments if it gets related to category of specifications
... it may be outmoded by the refinements we've gone through

Next teleconf: next week

Summary of Action Items

[NEW] ACTION: karl to give a better outline of the issue and to move forward the discussion on umbrella specs [recorded in http://www.w3.org/2005/05/16-qa-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.122 (CVS log)
$Date: 2005/05/17 15:26:11 $