karl: during Tech Plenary day,
there will be a panel on extensibility and versioning, with TAG
and other groups
... they would like to get someone from QA WG on this panel
Tim: what's the context exactly?
karl: discussion started with
coordination between QA WG and TAG
... extensions were not addressed the same way in TAG and QA
WG
... tension between extensibility and versioning, not handled
the same way
... also related question to format without a versioning
system
... panel will be around all these questions, whether
extensibility is good or not, versioning, etc
Tim: I did mention the versioning
question to the CSS WG
... the # of participants thinking that versioning was not
needed prevailed
karl: we need someone to represent the QA WG point of views
Tim: I could be interested in it
DaveMarston: me too, but Tim is probably a better candidate since he's formally participating in the QA WG
Tim: Dave and I could work together offline
Karl: I have some input too
... Also, it's always possible to participate from the
audience
ACTION: karl to respond to the panel organizers with the name of our candidates
ACTION: karl to send background information about panel on extensibility to Dave and Tim
Dom: I suggest that Tim and Dave should copy the WG mailing list on their resulting discussions
karl: another point related to
the Tech Plenary
... the TAG wanted to know whether we wanted to have a joint
meeting on this very topic
... as a follow-up to the comments we made on extensibility
back during WebArch Last Call
Dom: any specific points that could be addressed during such a meeting?
karl: there is a finding the TAG is writing on this topic
Dave: a related topic I would like to see addressed is when there are normative interdependencies between technologies with various levels/modules, etc.
tim: we have these questions in ATAG/WCAG too
Karl: does that concern also the TAG?
Dave: the QA group may be ahead of other groups wrt systematic thoughts about how to do so
[going around the persons present on the call: almost nobody would be available at the proposed time]
karl: will get back to the TAG to
let them know we can't do it during the tech plen
... we can always organize a joint teleconf afterwards
... Next item is about the questions from the WAI CG
... they had comments really about SpecGL that we'll have to
solve in their own time
... but there are also a few questions about how SpecGL applies
to their documents, esp. WCAG 2.0
... either we discuss that today, or we get someone from the QA
WG to help answer their questions
... for instance, they have an issue about extensibility:
they're not sure how it would apply to WCAG 2.0
... e.g. policy makers adding rules to WCAG 2.0
... they don't know how to deal with it
Tim: the WCAG 2.0 principles can serve as a basis for local versions laws
karl: this is the kind of
questions they have; also have some about "deprecated
features"
... I think someone from the QA WG should try and help them
solve their specific issues and see whether SpecGL answers
their questions
... if that raises specific issues, we can get them back into
our specGL issues
Tim: I'm participating in the
techniques teleconf
... I guess I could volunteer to help them
... I'll initiate the discussion in the WCAG WG and reports
back to QA
ACTION: Tim to initate the discussion in WCAG WG about the 8 questions raised - Karl will forward specific bugs numbers
tim: is this reasonable that WCAG 2.0 level A be required somewhere for W3C specs?
dom: pubrules already covers this, for WCAG 1.0 level A
karl: re xml:id
... thanks for Dave's analysis
... xml:id is probably going to be the 1st spec to be fully
compliant with SpecGL
... They've been very responsive to our comments
karl: I proposed a new text for
the section on error mechanisms
... wrt 4.5 GP A, in response to Ian Hickson's comment
... about the lack of definition of "must understand" / "must
ignore"
[failing comments from the WG, this is pushed back to a next teleconf]
karl: getting onto bug 1087
... the WAI CG would like us to asks to address accessibility
in specifications
... we already had that comment 2 years ago
... and we said it was out of scope of our document
Mark: as a general rule, I don't think we address content
Lynne: her argument was that to
write a good spec, you need to address accessibility
... but I agress with Karl that this out of scope
dom: what about putting this in an informal section?
mark: but then we'll get flamed for not mentioning this or that
dom: we can always put an appropriate disclaimer
karl: I wouldn't put it in a GP, since that would be untestable
lynne: what about putting in the scope section?
mark: but it's clearly out of scope
tim: but accessibility is important to have in mind when designing a spec
karl: but the list can get on for
ever
... it is indeed important to address a wide variety of
topics
... but they're not related to what we try to do in SpecGL
tim: what about putting somewhere in an informative part?
mark: there are 2 levels to
this
... we don't want to require specs to address security,
accessibility
... although I see no problem in saying that specs should be
accessible
karl: but what the WAI CG asked
was about topics addressed in the spec
... I like Lynne's proposal to put that in the scope
section
dom: I like the idea
... I think we should take the opportunity to say also that
it's a good idea to address topics like "accessibility, device
independent, i18n, security", etc
ACTION: Lynne to propose an addition to scope wrt accessibility, etc being out of scope but worth having in mind by 2005-02-16
karl: next issue, 1089
karl: questions about classes of products wrt "who or what" being clarified as "who and/or what"
Lynne: I think just changing to "and/or" is enough
[agreemnt on this]
RESOLUTION: changed 2.2 A to "and/or"
karl: issue 1091, dup of other
issues raised by Ian Hickson, Gary Feldman
... about prose vs formal languages
... opposite views on the topics
tim: not all technologies can use formal languages
dom: I think we should avoid
having a moral stance on formal language
... the current wording probably goes further than we
want
... we just want to give a technical hint on how to use
efficient formal languages
tim: could we just say "use formal languages if appropriate"?
mark: too vague
lynne: let's do as we did for profiles, saying "if you use formal languages" ...
dom: I agree
tim: I think the use of formal languages should be encouraged
dom: hearing what we say now about when to use formal language, I think we have a pretty definition on "if appropriate"
mark: with that and "if applicable", sounds good
dom: what about changing the title to "use formal languages if applicable" and move the priority stuff as a technique?
karl: I'll take another stab at rewriting the full good practice
ACTION: karl to rewrite GP 5.E about formal languages
tim: I got several comments that requirements and good practices were too hard to find
karl: next issue 1085, "more
detailed ToC"
... agree that we should get into deeper levels
tim: [asking whether we addressed deprecation in WCAG, noting that we didn't]
RESOLUTION: the ToC should go deeper to show requirements and good practices
dom: do we have an editorial version of SpecGL yet?
karl: not yet, but I can do it
ACTION: karl to publish an editorial version of SpecGL
RESOLUTION: next teleconf next week, Monday 14 Feb