See also: IRC log
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
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
patrick: somebody looking it up
for me
... it's coming
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
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]
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