Minutes Telcon 20030505 [corrected]

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

Received on Tuesday, 13 May 2003 10:32:42 UTC