Earlier email contained wrong version. Enclosed, please find corrected
version.
/Dimitris
---
QA Working Group Teleconference
Monday, 05-May-2003
--
Scribe: Dimitris Dimitriadis
Attendees:
(PC) Patrick Curran (Sun Microsystems)
(dd) Dimitris Dimitriadis (Ontologicon)
(KD) Karl Dubost (W3C, WG co-chair)
(PF) Peter Fawcett (RealNetworks)
(KG) Kirill Gavrylyuk (Microsoft)
(DH) Dominique HazaÃl-Massieux (W3C)
(LH) Lofton Henderson (CGMO - WG co-chair)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(DM) Dave Marston (IBM)
Regrets:
(SM) Sandra Martinez (NIST)
(AT) Andrew Thackrah (Open Group)
Absent:
none
Summary of New Action Items: [...to be filled in after telcon...]
none
Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2003May/0013.html
Previous Telcon Minutes:
http://lists.w3.org/Archives/Public/www-qa-wg/2003May/0006.html
Minutes:
1.) roll call 11am EDT, membership
2.) any Last Call reviews
Â Â Â Â Â Â Â Â - MathML review approval
3.) Spec Guidelines [1] (DH/LR)
Â Â Â Â Â Â Â Â - Last Call SpecGL issues [3], groupings [4]
Â Â Â Â Â Â Â Â - CP8.4 multiple discretionary items policy [2a]
specific proposal sent by DM. Any comments?
LR: looked at the proposal, two things unclear. First, in the changes
to 8.1, proposing to change the conformance requirements to "must
identify all discretionary item...". In the comments wording had been
added that DM, LH and DH did not fully agree.
DM: For the record, has pushed for the rewrite
LH: two comments: first, this used to be about discretionary choices
(8.4), is now about discretionary items. Unless an editorial slip,
scope has changed.
DM: deliberate change.
LR: OK with proposal.
LR: re: 8.4, Lofton has a problem with discretionary choices, doesn't
understand wording, confused with the rationale.
DM: point of 8.4 is about the issue of making choices or open ended
discretion available by policy level statements, not leaving choices
dangling throughout spec.
DH: not sure the wording is understandable by anyone else than us
LR: still don't understand
DM: description of consolidated policy for as many descretionary items
as possible. If not, you need to give a rationale on why the
consolidated policy is not used. Conformance measurement is that
throughout the entire spec, every time discretion is mentioned, it can
be associaated with a grand policy level choice or a rationale as
presented explaining that there is something outside the WG forcing
these to be discrete items.
LH: thinking about SVG for example, how are optional features ???
DM: are these various kinds of optionality inherited from an outside
standard?
LH: no, inherited by the WG not being able to make up its mind
DM: are they independent of one another? Then maybe we have to say
that's the rationale, the weakest one available.
DH: Lynne, do you now see what the checkpoint is about?
LR: yes, think so
DH: conformance requirement is way too complex for most people not
having background in QA stuff. Second, special wording is spread all
around.
LH: maybe the conformance requirements in 8.1 could be a three bullet
list. first bullet: indicate the rationale for discretionary items.
second: adresss whether there are unifying or consolidating policies.
third: must identify every individual discretionary item. since it's
broadened to be items instead of choices, it fits in nicely.
DM: would like to know if people are happy with things other than C
and F
LR: no problem with A, B, I think C now, D, and I think E. E adds to
the rationale of 8.3 to clarify consistency. Should 8.4 remain
separate, or be deleted or raised to the level of bullet in 8.1
DM: would like to keep them separate to avoid verbage tweaking. 8.1
would be overloaded if we tried to put goodness measure in that
guideline.
LR: Thinks they should be kept separate.
DH: should we take on the extensibility issue?
Â Â Â Â Â Â Â Â - extensions issue group [2b]
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --(15, 29.5, 35, 37, 38, 52, 73.5,
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 73.6, 75.4, 81, 100, 101 , 97)--
LR: issue 52, 73.5, 73.6, people object to big letters. Make the "NOT"
a "not" (non RFC2119-ized).
LH: issue 100 was saying that we shouldn't discourage extensibility.
LR: specifications do have extensions
LH: opposed for two reasons. the only person commenting was saying he
thought it was clear and well written. second, I think there is no
problem. If we get rid of the "NOT" it will be OK, the language is
about as neutral as you can be, still preserving the fact that many of
us have had bad experiences with extensions.
KG: We base our spec on extensible markup language.
LH: I asked of a counterexample, David pointed out that the only spec
which is like that, is XML. Is the operability downside justified? It's
a calculated decision. The interoperability downside doesn't go away.
MS: I believe you are arguing against implementors implementing
extensions. I agree there should be constraints, but most of the
constraints we have in there don't have much teeth.
KG: First, I disagree that XML is the only standard where you don't
have a choice. I can name three
LH: send them in
KG: There is a cost as far as how you implement, not if.
LR: delete the "or not allowed". moving on.
KG: still argues that we shoudl remove the third sentence.
LH: opposed
LR: any obcjection to change the whether to how? Editors will work on
this.
LR: Last call 38, already agreed to combine 9.1 and 9.2, already done.
Wording has to be modified anyway. We'll try to change the wording
then. No objections.
LR: 35 and last call 37 - any objections to keeping it as is? We
acknowledge that 9.3 may be redundant. No objections.
LR: Last call 29.5 - Some of this will be covered in the ExTech
document.
LR: should some wording be inserted to talk about useful ways to allow
extensibility or good things about extensibility? no.
LR: last call 81, last call 101 - alternatives to extensions.
LH: do we really need to mandate a mode to produce strict content?
DM: What happes with XML itself?
LH: it wouldn't pass level 3.
LR: should we leave this checkpoint in here? is it worth having in the
document? I'm saying let's get rid of it. Anyone feel strongly about
keeping it?
LH: not ready to get rid of it yet, want to look at the whole thing.
4.) Other pending SpecGL issue groups
Â Â Â Â Â Â Â Â - applicability/normative exclusion [2d]
Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â --(26, 28, 73.2, 80)--
Â Â Â Â Â Â Â Â - reserve topic: SpecGL-by-SpecGL [2c]
not adressed
5.) Adjourn
adjourned 5 minutes past the hour
6.) Overflow (12-12:30): available.
not used