W3C home > Mailing lists > Public > www-qa-wg@w3.org > January 2003

draft minutes qa wg f2f 20030107 afternoon

From: <dimitris@ontologicon.com>
Date: Wed, 8 Jan 2003 02:31:01 +0100
Message-Id: <200301080131.h081V1AB023911@mail.24-7webhosting.com>
To: www-qa-wg@w3.org

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

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 strcit 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 inst. 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 chkpoint 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 chkpoint 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 Tuesday, 7 January 2003 20:31:04 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:12 GMT