- From: Dimitris Dimitriadis <dimitris@ontologicon.com>
- Date: Fri, 17 Jan 2003 06:36:23 +0100
- To: www-qa-wg@w3.org
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