IRC log of qa on 2005-08-09

Timestamps are in UTC.

09:02:20 [RRSAgent]
RRSAgent has joined #qa
09:02:20 [RRSAgent]
logging to http://www.w3.org/2005/08/09-qa-irc
09:02:37 [dom]
Meeting: QA WG Dublin F2F Day 2 am
09:02:41 [dom]
Chair: Karl
09:03:41 [dom]
Present: Karl, Lofton, Patrick, Lynne, Mark, Richard, Dom
09:05:41 [dom]
RRSAgent, make log public
09:06:22 [dom]
Scribe: dom
09:06:31 [dom]
Agenda: http://lists.w3.org/Archives/Public/www-qa-wg/2005Aug/0004.html
09:06:47 [dom]
RRSagent, draft minutes
09:06:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
09:07:22 [dom]
Topic: Discussion around GP19
09:07:37 [dom]
Lynne: I think our current text is good
09:07:48 [dom]
... but I propose to add clarifications to the example
09:08:15 [dom]
-> http://lists.w3.org/Archives/Public/www-qa-wg/2005Aug/0022.html Lynne's rewrite
09:10:24 [dom]
Karl: works for me
09:11:32 [dom]
Dom: I think it does satisfy the editorial problem that has appeared during the discussion
09:11:53 [dom]
... wrt the more substantive problem, we already said we disagreed with Bjoern's comment
09:13:55 [dom]
RESOLVED: agreed to incorporate Lynne's change to the example in GP19
09:16:03 [lynne]
lynne has joined #qa
09:16:28 [dom]
Topic: Test Case data model
09:17:08 [dom]
-> http://esw.w3.org/topic/TestCaseMetadata Test Case Metadata
09:19:00 [dom]
karl: I propose "identification" should be renamed as identifier, as in Dublin Core (DC)
09:19:33 [dom]
patrick: I suggest we actually take the description from dublin core as well
09:20:22 [dom]
-> http://dublincore.org/documents/dces/#identifier Dublin Core definition for identifier
09:20:40 [dom]
patrick: so the description should be "An unambiguous reference to the test case"
09:20:55 [dom]
lynne: re rationale, "buys the ability to uniquely reference the test case"
09:21:15 [dom]
... a required element
09:21:33 [dom]
... I don't think there should be any restriction for the syntax
09:21:41 [dom]
karl: should we suggest URIs there?
09:22:10 [dom]
dom: would make sense to at least suggest it
09:22:27 [dom]
lofton: but doesn't that make it bound to the versioning aspect?
09:22:58 [dom]
karl: not necessarily, as in latest/this version in TR
09:23:19 [dom]
patrick: so we should recommend URIs as a good idea, but not as a restriction
09:23:58 [dom]
lynne: relevance, both during development and execution
09:24:22 [dom]
patrick: we should fix "running time" into "test execution" for consistency sake
09:25:37 [dom]
karl: what about example? do we have a real example to link to?
09:26:50 [dom]
-> http://www.w3.org/MarkUp/Test/HTML401/20030123/tests/9_1-BF-01.html HTML 4.01 Test Case with a unique identifier "9_1-BF-01"
09:27:15 [karl]
karl has joined #qa
09:27:26 [karl]
http://www.w3.org/MarkUp/Test/HTML401/current/tests/sec9_1-BF-01.html
09:28:23 [dom]
Patrick: N/A for test FAQ
09:29:41 [dom]
RRSAgent, draft minutes
09:29:41 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
09:30:08 [dom]
Dom: for SeeAlso, maybe Versioning?
09:30:18 [dom]
Lynne: put that as temporary item
09:30:38 [dom]
karl: next item, "name"
09:31:07 [dom]
patrick: we should change to title as in dublin core
09:31:15 [dom]
-> http://dublincore.org/documents/dces/#title Title definition in DC
09:31:43 [dom]
lynne: description is "the name by which the test case is formally known"
09:32:02 [dom]
patrick: rational is something more usable for humans than an identifier
09:32:24 [dom]
... I don't think it should be required, as sometimes the identifier is enough
09:32:28 [dom]
... syntax: text
09:32:37 [dom]
... relevance: both
09:32:46 [dom]
... test faq: N/A
09:33:44 [dom]
lofton: but isn't a title required for usability?
09:34:04 [dom]
patrick: I have some test suites I've been using for more than 7 years without anything but identifiers
09:34:22 [dom]
lynne: maybe we should add a comment about this?
09:34:35 [dom]
karl: that's a good idea
09:34:46 [dom]
patrick: so let's add a comment field with that point made
09:35:01 [dom]
... and this also means that SeeAlso should reference identifier
09:36:46 [karl]
http://www.w3.org/Style/CSS/Test/CSS2.1/current/t0510-c25-pseudo-elmnt-00-c.htm
09:37:29 [dom]
Karl: example from CSS Test suite "Pseudo-elements in selectors", http://www.w3.org/Style/CSS/Test/CSS2.1/current/t0510-c25-pseudo-elmnt-00-c.htm
09:37:49 [dom]
karl: next is "description"
09:38:27 [dom]
lynne: definition "a representation in words of the nature and characteristics of the test case"
09:38:35 [dom]
patrick: also exists in Dublin core
09:38:55 [dom]
karl: rational?
09:39:35 [dom]
lynne: to provide additional context about the test case
09:39:40 [dom]
s/rational/rationale/
09:39:49 [dom]
dom: not required, AFAICT
09:39:57 [dom]
patrick: syntax: hypertext
09:40:01 [dom]
... relevance: both
09:40:30 [dom]
... test faq: N/A
09:41:51 [dom]
Dom: how does it related to purpose? is it redundant?
09:42:36 [dom]
... I think a broader description than the purpose can be useful
09:42:52 [dom]
Lofton: [reading an example from WebCGM TS illustrating how they complement each other]
09:43:06 [lofton]
lofton has joined #qa
09:43:13 [lofton]
Test basic CGM-to-HTML link, from a Application Structure with
09:43:13 [lofton]
linkuri APS Attribute within the CGM, to a whole HTML document, with
09:43:13 [lofton]
no behaviors or fragments associated with the link.
09:43:42 [dom]
Lynne: see also: purpose
09:44:17 [dom]
karl: next item is "status"
09:44:38 [dom]
... useful for development process, but not necessarily at executing test time
09:44:43 [dom]
patrick: depend on your test suite
09:44:59 [dom]
... we have a test suite that contains buggy tests marked as excluded but that we still ship
09:45:00 [lofton]
That descriptions comes from WebCGM test case linking-basicC2H-BE-02
09:45:11 [dom]
... in this case, it is relevant at execution time
09:46:05 [dom]
lynne: there are different states before and after release of the test suite
09:46:21 [dom]
s/there are/there may be/
09:46:27 [dom]
karl: is it required?
09:46:57 [dom]
patrick: I don't think it should be required; maybe "recommended" (vs optional)
09:47:16 [dom]
lofton: I think it should be required, maybe with a default value
09:47:37 [dom]
... it's not reasonnable to release a test suite without that
09:47:57 [dom]
lynne: this wouldn't apply to some of my test suites
09:48:18 [dom]
... we go through several stages
09:50:55 [karl]
marc: why don't we just call it "None" but required when someone don't want to use it
09:55:43 [dom]
[somewhat consensus around "recommended", although lofton and mark think "required" is better]
09:56:40 [dom]
karl: nothing relevant in DC, as far as I can tell
09:56:48 [dom]
... what about description?
09:58:24 [dom]
patrick,others: "one of an enumerated list of values that can be used to track the state of a test at a given time"
09:59:45 [dom]
karl: rationale?
10:01:17 [dom]
patrick: during development, it can be helpful to track the test through the review process
10:01:59 [dom]
dom: it helps assess a confidence level with the test, maybe?
10:02:06 [dom]
[rough agreement]
10:02:42 [dom]
dom: syntax?
10:02:54 [dom]
patrick: enumerated list
10:03:32 [dom]
karl: [example from WCAG]
10:03:34 [karl]
http://www.w3.org/WAI/GL/WCAG20/tests/ctprocess.html
10:03:42 [dom]
lynne: that's for development time, though
10:04:27 [dom]
patrick: after release, this could be "good, under investigation, withdrawn"
10:04:46 [dom]
... or "correct" instead of "good"
10:05:34 [dom]
... test faq: Q6, http://www.w3.org/QA/WG/2005/01/test-faq#review
10:05:45 [dom]
... "6. What should we do with test contributions we receive?"
10:17:43 [dom]
RRSAgent, draft minutes
10:17:43 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
10:21:51 [karl]
karl has joined #qa
10:22:35 [dom]
Patrick: let's skip versioning for now, I suggest
10:22:42 [dom]
Karl: next is "link to spec"
10:23:06 [dom]
... maybe relates to dc:source
10:23:22 [dom]
patrick: I don't think we should use the word "source"
10:24:13 [dom]
... but we could say this is equivalent to dc:source?
10:24:22 [dom]
... I'm not sure there is a benefit to reference this
10:24:52 [dom]
karl: so do we keep the name "link to spec"?
10:26:18 [dom]
patrick: what about "spec reference"?
10:27:05 [dom]
... description would be "identification of the portion of the specification tested"
10:27:48 [dom]
patrick: rationale is really close to what we put in purpose, isn't it?
10:28:39 [dom]
lynne: "to provide the tracability from the test back to the spec"
10:28:47 [dom]
dom: required?
10:28:49 [dom]
lynne: yes
10:28:52 [dom]
patrick: yes!
10:29:13 [dom]
dom: syntax?
10:29:36 [dom]
patrick: ideally, a URI with an XPath pointer, or a free form hyper text
10:29:50 [dom]
... we should put as comments that it should be as precise as possible
10:30:00 [dom]
... e.g. pointing to a particular string rather than a whole section
10:30:11 [dom]
dom: relevance: both
10:30:31 [dom]
patrick: test faq: Q8 is about coverage
10:30:55 [dom]
lynne: for examples, DOM and XML have this I think
10:32:02 [dom]
patrick: the examples in Q8 can be re-used
10:32:11 [dom]
... e.g. the HTML 4.01 tests
10:34:36 [dom]
dom: looking at the HTML test suite, they annotate their assertion with their RFC 2119 level requirement
10:34:45 [dom]
... i.e. "must" vs "should"
10:34:53 [dom]
... is that something we should record in our data model?
10:35:15 [dom]
patrick: it somewhat relates to the variability discussion
10:35:21 [dom]
lynne: or grouping?
10:35:30 [dom]
patrick: let's come back to this later
10:36:49 [dom]
lynne: going back to the spec ref, we should have an example of each type of the syntax
10:39:08 [dom]
patrick: ideally, we could constrcut an xpath uri to match the example we had above
10:39:49 [dom]
karl: what about "link to issue"?
10:40:32 [dom]
patrick: would argue against that, too specific
10:40:43 [dom]
dom: what about a more general "see also"?
10:40:50 [dom]
patrick: sounds good
10:41:14 [dom]
... could link to an issue database, a discussion in a mailing list
10:42:09 [dom]
dom: so title, "see also"
10:42:36 [dom]
patrick: description is a list of references to external resources relevant to this test case
10:42:45 [dom]
... 2 use cases: issue in bug db, discussion ml
10:43:17 [dom]
... rational: useful to be able to link to external resources that provide more context to the existence of the test case
10:43:24 [dom]
dom: not required, obviously
10:43:32 [dom]
patrick: syntax would be list of URIs
10:44:16 [dom]
... relevance: probably more development than execution, but can be useful also after release when a test is challenged
10:44:21 [dom]
... e.g. to link to a bug report
10:44:37 [karl]
http://www.w3.org/QA/WG/2005/01/test-faq#bugs
10:44:43 [dom]
... test FAQ Q15 refers to bugs in a test suite, so maybe relevant
10:45:32 [dom]
... examples should reference the 2 uses cases
10:46:21 [dom]
karl: it could also be other test cases?
10:46:25 [dom]
patrick: I guess so
10:47:07 [dom]
... which makes me think that a URI as such isn't useful if there is not human-readable info about the said URI
10:47:25 [dom]
... so syntax should be a list of pairs of (URI, human readable title)
10:48:01 [dom]
dom: next one is "dependencies" that we suggested should be called "pre-conditions"
10:48:37 [dom]
... separate from input
10:49:11 [dom]
patrick: description: "conditions that must be met before this test is executed"
10:50:14 [dom]
... rationale: any such condition must be understood before the test case can be successfully executed
10:50:21 [dom]
... syntax: hypertext
10:50:26 [dom]
.. relevance: both
10:50:31 [dom]
... test faq: N/A
10:51:05 [dom]
... required: not
10:51:38 [dom]
... I actually think stateless test suites are better
10:51:56 [dom]
lynne: but not every pre-conditions come from dependencies between test cases
10:52:03 [dom]
... so not necessarily bad
10:52:29 [dom]
patrick: as an example, such a server process must be running for the test case to be executable
10:53:36 [dom]
patrick: let's skip grouping and variability-driven filtering criteria for now
10:53:46 [dom]
dom: next are "input" and "expected results"
10:54:27 [dom]
patrick: name is "input" or "inputs"?
10:58:52 [dom]
... description: "parameters or data that must be supplied to the test at execution time"?
11:00:03 [dom]
[discussing about whether "supplied to" is appropriate for a test]
11:00:20 [dom]
karl: "parameters or data that are needed for the test execution"
11:00:29 [dom]
patrick: rationale is obvious
11:01:02 [dom]
... optional since in some cases it doesn't apply
11:01:18 [dom]
karl: syntax, none, since that's implementation dependant
11:01:25 [dom]
... relevant, both
11:01:52 [dom]
patrick: but probably more importantly at execution time
11:02:25 [dom]
lofton: I think it should be required, with "none" as a possibility
11:02:41 [dom]
patrick: ok, I agree
11:02:45 [dom]
karl: I disagree
11:02:50 [dom]
Lynne: me too
11:03:35 [dom]
... I may have an entire test suite without input at all
11:04:21 [dom]
[optional seems to gain back consensus]
11:04:30 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
11:04:59 [dom]
patrick: test FAQ Q11 may be somewhat relevant
11:05:47 [dom]
karl: example could be HTTP interactions?
11:06:18 [dom]
... e.g. an HTML file may be served under different conditions (encoding, MIME Type)
11:09:10 [dom]
dom has joined #qa
11:09:39 [dom]
RRSAgent, draft minutes
11:09:39 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
11:10:00 [dom]
RRSAgent, bye
11:10:00 [RRSAgent]
I see no action items
12:59:19 [RRSAgent]
RRSAgent has joined #qa
12:59:19 [RRSAgent]
logging to http://www.w3.org/2005/08/09-qa-irc
13:00:05 [dom]
ScribeNick: karl
13:00:11 [dom]
Topic: Afternoon session
13:00:27 [karl]
Chair: Dom
13:01:07 [karl]
dom: there is still one easy target - expected results
13:01:21 [karl]
patrick: expected results or output
13:01:41 [karl]
dom: we had the discussion yesterday, that sometimes it's not an ouput
13:02:04 [karl]
... we keep expected results. agreement of the WG
13:02:45 [karl]
(discussion between people about the definition)
13:03:19 [karl]
description: The results that a correct implementation will produce
13:04:40 [karl]
lynne: the results is know a priori before running the test then we need something which capture that
13:04:43 [dom]
patrick: "the results that a conformant implementation is expected to produce"?
13:05:23 [karl]
dom: I don't think we need a rationale for something which is that simple
13:05:35 [karl]
... required is mandatory
13:05:40 [karl]
patrick: yes
13:05:49 [karl]
dom: syntax is implementaiton dependant
13:06:20 [karl]
dom: what about tesfaq?
13:06:29 [karl]
patrick: TestFAQ 9
13:07:57 [karl]
... in test FAQ 9, I don't like the word outcome
13:08:19 [karl]
dom: no link for the test FAQ 9
13:08:29 [lofton]
lofton has joined #qa
13:08:39 [karl]
patrick: before we had the CSS Test Result: background green
13:08:45 [karl]
http://www.w3.org/Style/CSS/Test/CSS2.1/current/t0510-c25-pseudo-elmnt-00-c.htm
13:09:10 [karl]
See also - nothing in particular
13:09:33 [karl]
dom: we are done with the simple ones
13:09:42 [karl]
... should we tackle the difficult ones
13:10:44 [karl]
... Grouping is a super property of variability
13:11:01 [karl]
lofton: David proposed grouping?
13:11:20 [karl]
dom: david proposed specific driven variarability
13:13:07 [karl]
patrick: generic keywords would be useful to identify for the test case.
13:13:24 [karl]
dom: keywords are not a property of test case
13:14:54 [karl]
patrick explaining his position about dealing with grouping
13:15:31 [karl]
patrick: Do we reduce grouping and variability to only one property.
13:16:03 [karl]
lofton: (reading the comment of variability in the wiki)
13:16:27 [karl]
lofton: it seems that David agrees with the notion of grouping
13:16:40 [karl]
patrick: yes you can have multiple ways of grouping
13:17:25 [karl]
dom: mAybe it's so generic than it's not tied to the test case, and we could write prose to encourage people
13:17:36 [karl]
... to use grouping for the process management
13:18:03 [karl]
patrick: There may be multiple ways of slicing data in different sets.
13:18:17 [karl]
dom: we should maybe separate it
13:18:43 [karl]
patrick: maybe it fits in this template, but I see the problem of free form.
13:19:07 [karl]
dom: Maybe it deserves more space. It something we should add before in prose
13:19:21 [karl]
patrick: it's something which might be addressed in the test FAQ
13:21:22 [karl]
dom, patrick: Grouping? (maybe to be modified if a better name)
13:21:28 [karl]
karl: what about keywords?
13:21:34 [karl]
dom: too specific.
13:21:36 [karl]
karl: ok
13:24:37 [karl]
... after discussion Description: "mechanism for classifying test cases into groups"
13:25:46 [karl]
patrick: you want to be able to deal with variety of subsets
13:26:16 [karl]
... then the rationale will be
13:26:26 [karl]
lynne: agreed
13:26:43 [karl]
dom: I think we should include some examples
13:27:39 [karl]
karl: why should I care? what will you answer me?
13:28:01 [karl]
patrick: A subset which shares some common characterics.
13:28:25 [karl]
... To be able to select a subset which shares common characteristics.
13:28:38 [karl]
... This is the rationale.
13:29:00 [karl]
Required: no. agreement of the group
13:30:08 [karl]
patrick: I would say one or more enumerated list
13:30:14 [karl]
lofton: it's too limited
13:30:30 [karl]
... the syntax is variable and include blablabla
13:31:17 [karl]
patrick: syntax: Implementation dependent, some possibilities include naming conventions, enumerated lists, and naming conventions, and others.
13:31:27 [karl]
dom: relevance?
13:31:32 [karl]
... both
13:31:37 [karl]
dom: TestFAQ?
13:32:18 [karl]
patrick: we need to add a question to the Test FAQ
13:32:29 [karl]
... how to deal with DOV
13:32:40 [karl]
dom: I don't think we should have DOV in the question
13:32:54 [karl]
patrick: something explaining the DOV.
13:33:03 [karl]
dom: Example?
13:33:26 [karl]
... interactive versus automated.
13:33:33 [karl]
... voice versus dtmg
13:33:42 [karl]
s/dtmg/dtmf/
13:34:11 [karl]
... tests marked for various profile
13:34:44 [karl]
... SVG Tiny/Full had a subnaming convention.
13:35:11 [karl]
dom: Comments: @@to be done with the capture of the discussion@@
13:35:47 [karl]
lofton: what about DOV keyword?
13:36:00 [karl]
dom: we just discussed that it was a kind of grouping
13:36:13 [karl]
... what would be the gain?
13:38:30 [karl]
lofton: For groupings other that driven variability ones, arbitrary groupings, I don't think there's a compelling argument for calling them recommended.
13:38:48 [karl]
... for variability it's tied to the conformance clause
13:39:10 [karl]
dom: but you said the recent SVG Test suite didn't deal with it
13:39:25 [karl]
lofton: the first incarnation dealt with it.
13:40:02 [karl]
... you can't test if you don't have grouping for variability
13:40:47 [karl]
lynne: maybe we need something for conformance and variability testing
13:41:36 [karl]
lofton: I don't think it should be buried in grouping
13:44:11 [karl]
karl: I don't think it's part of the test suite
13:44:22 [karl]
s/test suite/test case/
13:45:00 [karl]
dom: lofton is saying that it's part of the conformance criteria and the test case should say which profiles belong to
13:45:38 [karl]
lynne: the reasons you would like to group is related to the conformance.
13:48:14 [karl]
karl: could we work with a practical example?
13:48:20 [karl]
... (discussion)
13:55:01 [karl]
... explaining that a specific test case can be called by many specifications
13:56:17 [karl]
... and then we will have a huge list of conformance grouping.
13:56:27 [karl]
discussion between lynne and patrick
13:57:50 [karl]
patrick: we have to be very explicit in the examples and comments about the ways to use grouping
13:57:59 [karl]
... there are many different cases.
13:58:34 [karl]
karl: (examples for WebCGM, XSLT, Java world, xml:lang attributes, etc.)
14:01:41 [karl]
karl: I think it's a meta level which is not tied to the test case
14:01:53 [karl]
lofton: yes I can buy that.
14:02:14 [karl]
dom: (it seems we have an agreement)
14:02:21 [karl]
... versioning?
14:02:31 [karl]
patrick: we will have the same problem.
14:03:05 [karl]
dom: version of the test case? version of the test suite? version of the specification?
14:04:52 [karl]
patrick: a test which is valid for a spec A at a time doesn't say that the test will not be useful for another spec B later on.
14:05:24 [karl]
dom: it seems to be another kind grouping
14:06:03 [karl]
karl: how do we relate versioning and status?
14:06:24 [karl]
dom: you might want to keep version control for the development of your test case.
14:07:00 [karl]
patrick: Identifier blablabla version X for keeping an history in time. Ok I agree with that
14:08:11 [karl]
lynne: this is the version of the test itself.
14:08:19 [karl]
dom: Name: version
14:12:22 [karl]
QAWG: Description: "Identifier which allows one to distinguish between different revisions of test case"
14:13:11 [karl]
QAWG: Rationale: "It @@provides@@ an history of the evolution of the test case."
14:13:21 [karl]
QAWG: Required yes
14:13:36 [karl]
QAWG: Relevance: both
14:14:25 [karl]
QAWG: Syntax: Free to implementation (see examples)
14:16:14 [karl]
QAWG: TestFAQ: Link 14.
14:16:47 [karl]
QAWG: Examples: look at CSS TS with latest etc. @@@@
14:18:14 [karl]
(break)
14:34:33 [karl]
QAWG: name: Contributor
14:34:50 [karl]
... See Dublin Core
14:35:41 [lofton]
lofton has joined #qa
14:37:42 [karl]
... discussion about ownership, about people submitting test but didn't want to assume the management of the test
14:39:05 [karl]
patrick: you might want to know, who did this test so that it can be fix by the same entity who created the test.
14:41:12 [karl]
dom: we have several questions.
14:41:20 [karl]
... do we keep the metadata
14:41:26 [karl]
... do we keep that name
14:42:00 [karl]
lynne: I want to know who and/or where the test case came from. I need at least one of those.
14:43:20 [karl]
patrick: you want to be able to identify the legal ownership of the test before the donation.
14:44:02 [karl]
QAWG: name chosen is Contributor
14:47:08 [karl]
... description: "Individual or organization that contributed this test case."
14:48:06 [karl]
... Rationale: "It might be important to track the origin of the test for technical reasons, legal issues, modifications, etc."
14:49:35 [karl]
... Required: optional
14:49:59 [karl]
... Syntax: hypertext
14:50:10 [karl]
... relevance: primary development
14:50:45 [karl]
... TestFAQ: Question 10
14:51:11 [karl]
... Example: XML Test Suite attribution to different contributors
14:52:49 [karl]
... includes contribution from Microsoft, IBM, Sun, etc. @@link to an example@@
14:52:56 [karl]
dom: dates?
14:54:07 [karl]
karl: we can have dates about many things
14:54:19 [karl]
dom; we should skip it
14:54:35 [karl]
lynne: wait a minute, I don't want to get rid completely of it.
14:55:54 [karl]
karl: I agree with lynne. And I think we should deal with it in the introduction.
14:56:26 [karl]
QAWG: It needs to be discussed somewhere.
14:56:44 [karl]
Lynne: Maybe in a note section after the metadata elements
14:56:54 [karl]
karl: agreed
14:57:10 [karl]
QAWG: Types: it's just a kind of grouping
14:57:21 [karl]
... everyone agreed
14:57:34 [karl]
QAWG: Source?
14:57:41 [karl]
... Not that important
14:57:54 [karl]
QAWG: Language?
14:58:00 [karl]
... should be like date in the note.
14:58:24 [karl]
... Coverage?
14:58:37 [karl]
... Dropped
14:58:42 [karl]
... Rights?
14:59:48 [karl]
patrick: copyrights are dealt with a tangible form already. We should not try to address in a particular way.
15:02:30 [karl]
... we may be stepped on lawyer's feet.
15:02:51 [karl]
dom: We are not saying how they should be managed, we are giving a pointer.
15:05:14 [karl]
karl: it's a pointer to the rights, not the rights
15:05:31 [karl]
QAWG: Rights
15:05:36 [karl]
... description
15:06:00 [karl]
... Description: Information about rights held in and over the test case.
15:07:59 [karl]
... Rationale: Publishers and Users of the test case need to know where the legal rights lie
15:08:23 [karl]
... Requires: Optional
15:08:45 [karl]
... Syntax: Ask your lawyer.
15:08:52 [karl]
... Relevance: both
15:09:11 [karl]
... Test FAQ: Q. 10
15:10:37 [karl]
... Examples: @@To find an example@@
15:10:56 [karl]
... Priority? no interest
15:11:06 [karl]
... References? no interest
15:11:40 [karl]
See mail for the previous discussion: http://lists.w3.org/Archives/Public/www-qa-wg/2005Aug/0020.html
15:11:57 [karl]
dom: what do we do with that?
15:29:37 [karl]
QAWG: We decided to publish this as a W3C WG Note. Patrick Curran will write the prose, introduction + notes + Issues, The text will be reviewed by Richard Kennedy
15:29:55 [karl]
... The text will be put in a ready to publish form by Karl
15:30:07 [karl]
... before August 31.
15:31:44 [karl]
dom: what do people think about creating actual schema for this Test Case Model.
15:31:49 [karl]
QAWG: Great Idea
15:32:46 [karl]
karl: do we try to gather people around it?
15:33:15 [karl]
patrick: We should try first to create a first version of an XML Schema and/or RDF Schema and try to gather people after it.
15:33:56 [karl]
... I would focus more on tools and very practical things.
15:34:02 [karl]
karl: by tools?
15:34:56 [karl]
patrick: something concrete and specific, the schema is too abstract, but something that can be usable: tools, programs, templates
15:35:03 [karl]
... that might interest people to work on it
15:36:46 [karl]
dom: Agenda for tomorrow morning. QA IG deliverables for rechartering.
15:36:51 [karl]
... teleconferences
15:36:58 [karl]
... next F2F?
15:37:14 [karl]
lofton: Next TP in France end of Feb 2006.
15:37:47 [karl]
karl: Basically future work
15:38:00 [karl]
patrick: shopping list of what we could for the next months
15:38:49 [dom]
RRSAgent, draft minutes
15:38:49 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
15:38:53 [karl]
ADJJOURNED
15:39:50 [dom]
Meeting: QA WG Dublin F2F Day 2
15:39:52 [dom]
RRSAgent, draft minutes
15:39:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2005/08/09-qa-minutes.html dom
15:43:53 [lofton]
lofton has left #qa