WCG telecon 16 December 1999





IJ like the requirements doc.

CMN lots of deliverables.

WC think they are doable?

WL what's a requirements doc?

CMN think charter should specify it.

IJ e.g. for XML

enumerate what final product must do.

WC think it is helpful.

JW requirements list is perfectly reasonable if it doesn't become a complex document. must be quick to produce so work can proceed.

IJ XML groups have formal process for creating Requirements documents. They do revise. Publish as notes. Changes should decrease over time.

WC many deliverables i am intending to be quick turn around. they are all linked.

JW when defining testing procedure one has to be sure not excluding evolving features.

WL like style sheets?

JW for audio, the feature (abbr) does not make a difference in visual media unless attach a style sheet. testing procedures should not excluded because of technologies that don't exist today.

WC want to ensure they pass muster.

CMN should not be a deliverable, but the way we work. too much overhead. testing crosses into review activity that's bouncing around. if that happens under GL then makes sense. Otherwise, be in ER or EO or a new activity.

JW it must have been demonstrated that the techniques can be implemented as a basic requirement of W3C process. Requirement in charter. But, in SVG you need a degree of support w/in an AT that has not been worked out yet. Therefore implementors won't be interested in developing support for until it becomes a recommendation. Often it becomes a feasibility test.

IJ what if Techniques becomes a test suite. each section is its own document. the markup is live. you can see if your browser supports it, if you want to implement it.

WL should it be a deliverable?

WC yes.

CMN if put a technique in tech doc have to demonstrate that it works.

JW agreeing with CMN. there should be a requirement in charter re: deliverables that implementation or implementation feasibility be demonstrated. more flexible.

WL what if "revised, more comprehensive, and better tested."

JW could be deemed to cover. but make it more specific. dependency on user agents.

IJ more of a sense of the procedure?

@@ JW the guidelines that we choose will or will not take into account user agent discrepancies.

IJ that's a statement for the requirements document.

WC explains dream of "browsercaps" like database. perhaps work with ER to create the automatic generation.

JW should not be deliverable. position remains the same.

WC then how represent the testing idea?

IJ requirements document.

WL #7 should be included in #4. it's part of the techniques document.

IJ agree it's a way of working. i like the idea of a database. a document should be a database and you query for what you want. it could be techniques database, then don't produce techniques document anymore.

CMN we still produce a document, but not the same as what currently exists.

JW possibility isn't it?

IJ WC's suggestion is important, built into how we work.

JW useful to set it up, as well as the user agent support page to have examples to be tested. don't know what UA is doing in terms of testing the techniques.

IJ not much. 1st round was to get people to get stuff. we're still not editing them.

WC so this is a process not deliverable. other comments?

JW feasibility of implementation is in the charter or in requirements document.

WC requirements doc for guidelines should not include techniques, very different documents.

IJ integrate matrix into checkpoints? document decision, who it is for, for each checkpoint. see matrix more integrated into checkpoints. clearly document which groups are affected.

WC not sure want to tie it to a document.

JW the impact of which shall have been identified by the working group.

IJ bullet 3 lists supporting documents, including the matrix.

WC then list minutes as deliverable if they are also just process?

IJ there is something that you have to show that you address all of the issues.

WC other issues?

IJ dependency with I18N and mobile.

WC highlight within PF section?

JW I18N also working on guidelines. therefore, direct dependency be better.

IJ I18N is like WAI in that it has some overall applicability to all groups. PF through mobile is appropriate.

WC what's the process?

IJ need approval from working group, Director or W3M before going to AC. AC has 1 month to repeal. as soon as charter says "ok" it becomes active. when announce groups existence, announce call for participation.

JW judy will put that to the interest group.

WC we want to send this to the director on...

IJ get it on the last W3M agenda for the year and secure a commitment from Janet to send it out on the 4th.

@@WC make edits, post tonight, send e-mail.would like to give people until next wednesday to review. then send to director for next w3m meeting (whenever that is). ask janet for publication date.

WL want to see example of techniques as database rather than document.

IJ go to W3C CSS test suite.

End of charter report

IJ you kept a couple section that I suggested deleting. I've already


WC 1st 6 months focus on Techniques, then kick into Guidelines work.

JW yes, Techniques needs work and can feed back into Guidelines.