Minutes QA WG F2F 20030107, afternoon [FINAL]

All,

Having received no comments on these minutes, they should be considered 
final. Some corrections in this version (mainly spelling).

---

Minutes: F2F Seattle QA WG Meeting
07-January 2003, afternoon

Scribe: Dimitris Dimitriadis

Attendees:
(KD) Karl Dubost (W3C, WG co-chair)
(PF) Peter Fawcett (RealNetworks)
(LH) Lofton Henderson (CGMO - WG co-chair)
(OT) Olivier Thereaux (W3C)
(KG) Kirill Gavrylyuk (Microsoft)
(LR) Lynne Rosenthal (NIST - IG co-chair)
(MS) Mark Skall (NIST)
(dd) Dimitris Dimitriadis (Ontologicon)
(DH) Dominique Hazael-Massieux (W3C)

Guests:
Tele-connection
(DM) David Marston
XQuery Test Group, Microsoft [Arrived at lunch, left after SOAP TS 
presentation]
(JL) Jinghao Liu
(MR) Mike Rorke
(AS) Ana Schmidt
(KS) Kuen Siew

Absent:
(AT) Andrew Thackrah (Open Group)
(JM) Jack Morrison (Sun)
(SM) Sandra Martinez (NIST)

Agenda: http://www.w3.org/QA/2003/01/agenda-detail

Summary of New Action Items:
Action item on Lofton to provide new checkpoint for Testable Assertions
Action item: Editors must reread the document and introduce consistent 
useage of "strict conformance"
Action item on editors to check that each DoV has a checkpoint about 
relationship with other DoV


Soap Test Suites Overview
(KG): similar to XSLT framework. XQuery will contain appr. 10.000 tests 
when released [PowerPoint presentation by KG, will be made available to 
the WG].
Test Markup is basically copy pasted from the specification, no 
specific test markup language.
Test Case is a scenario.

(Spillover from morning session)
(LH): extensibility section in OpsGL. Please look at it so that the WG 
can decide what to do with it tomorrow.

(Spec GL)
(DH) Alex Rousskov's comments and issues 
(http://www.w3.org/QA/WG/2003/01/AR-SpecGL-comments-1220.html)
002: high priority issue
009, 010, 011, 012, 016, 019, 022, 023, 025: substantive

Discussion on issues
related to 99:
What is a test assertion (TA)?
Does SpecGL include TA?
Should SpecGL require TA for all specifications?
(discussion on what a TA is, on the one hand, and how it is 
syntactically represented, on the other)

(MS) what level of precision/specificity is required for it to be 
testable? all MUSTS could be argued to be TA. On the other hand, it may 
require a higher level of specificity

(KG) Not every TS is an independent atomic entity. It's similar to a 
function in a program.

(discussion on what a specification author should do: write clear specs 
only, or also supply test assertions)

(DH) we need to have a checkpoint on requiring requirements in 
specifications.

(MS) if we put TS in as chekpoints, what priority should they be?

(DM) 3 for the short term future, intending to make it a stricter 
priority later on.

(LH) should we create a new checkpoint for TA? Change "to fulfil" into 
"conformance requirements". Change the title of guideline 13 into 
something like "identify all conformance criteria".

(all) agreed.

Action item on Lofton to do so.

(DH) Prio 2 or 3  for providing TA?

(DM) 3, only for the short term, ideally migrate to 2

(LH) would say 2/3 but not 1

Prio 2/3 for TA?

LR: 3
MS: 2
DD: 2
KD: 3
KG: 2
LH: 2
DH: 3
PF: 2

(resolution): prio 2

Issue 110:
(DH) One of the checkpoints I have a hard time understanding. Currently 
it says "distinguish requirements from product-specific features"

(DM) when you have anything but strict conformance, you want to divide 
the possibility of having more than the required features into 
extensions/more than the minimum (but somehow within the anticipated 
range of variants the spec allows for).

(MS) How could you not have extensions? You're still not allowing 
extensions, which is the defintion of stric conformance.

(DM) What about natural languages?

(MS) As long as you prohibit extensions, yes

(DM) The maximum set of features in that case is not the same as the 
minimum

(MS) if you are correct, I suggest to take out "strict conformance"

(DH) First thing, conformance requirement as written is not clear 
enough, then the question of clarifying the role of extensions, strict 
conformance etc

(DM) We could take out the term "strict conformance" but we have a 
definition in 3.2. If we only want to impact 3.3, we just say something 
about anticipated variability that does not get implemented by way of 
extension (implementation-dependent feature)

(DH) the whole checkpoint should beb rewritten

(MS) Anything that is variable within the spec, is not a variant, but 
an extension. What's the reason for having this checkpoint?

(DM) Reason for anticipating extensions/non-extensions, a way of saying 
implementing two languages instead of one does not constitute an 
extension

(MS) how is this enabling ckpoint 9 to work?

(LR) I don't see the reationale for having it

(MS) agree

(LH) I see the distinction between extension and extended capability of 
standard functions, not sure of seeng the value of having an extra 
checkpoint

(DH) agree to remove checkpoint 3.3?

(all) yes

Chckpoint 3.2 (issue 109)

(DM) If we drop 3.2 entirely, we have nothing in the guideline that 
says anythong about conformance policy, whereas guideline 9 still 
requires this

(DH) Any objection to remove checkpoint 3.2?

[no objections]

(DH) should we merge guideline 3 and 10?

(DM) we split it intentionally to allow for the difference regarding 
Dimensions of Variability, 3 discusses this, 10 writes about it

(LH) should any of the verbeage from 3.2 migrate to 9 (suggestion by DM 
to move the second paragraph of 3.2 to 9)?

(LH) Do we move the definition of "strict conformance" to GL9?

Yes

(LH) Does strict-by-class concept of Chkpoint 3.2 get moved to GL9?

Yes

Action item: Editors must reread the document and introduce consistent 
useage of "strict conformance"

(LH) definition should allow for extended features and so forth

[David Marston leaves]

(DH) proposal: add a checkpoint to guideline 9 saying that specifying 
relationships between extensions and other DoV

Yes, including specific examples for strict-by-class

Action item on editors to check that each DoV has a checkpoint about 
relationship with other DoV

Issue 109 closed

Alex Rousskov's issues

002: high priority issue
009, 010, 011, 012, 016, 019, 022, 023, 025: substantive

001: done. Use conformance requirement instead.

005: Lynne suggests taking the second section of Alex's rationale.

Received on Friday, 17 January 2003 00:35:33 UTC