Fwd: Untangling the Testable Assertions thread

QAWG -- I'm sending this for inclusion in the WG archive, and as a 
reference for Montreal f2f discussion.  It comes from some off-line 
discussion that Dimitris and I have been having...

>Date: Sun, 9 Jun 2002 23:07:49 +0200
>Subject: Untangling the Testable Assertions thread
>From: Dimitris Dimitriadis <dimitris@ontologicon.com>
>To: Lofton Henderson <lofton@terminal.rockynet.com>
>X-Mailer: Apple Mail (2.481)
>X-RCPT-TO: <lofton@terminal.rockynet.com>
>
>[...]
>As I mentioned earlier, here's the summary and roadmap on this thread. 
>I've stressed issues that deserve looking into more carefully and also 
>propose to divide the thread into separate issues. Also, the list in the 
>end of this post is not exhaustive, please provide feedback.
>
>Initially, I'd also consider sending this summary to the W3C Chairs 
>mailing list, which I propose that Lofton do.
>
>These issues will be discussed in next week's QA WG F2F in Montreal, so 
>any additional feedback is more than welcome.
>
>Scott's original intentions were:
>
>    Allow an external document (test case, erratum, email, etc.) to point
>    directly at a "testable" normative sentence in a Recommendation.
>    Encourage document editors to view some of the sentences as "test
>    assertions" and to write them in a style that conveys precisely what
>    they declare.
>    Explore possibilities for machine processing of testable sentences in
>    the future.
>    Link error assertions to error catalogues (see the work that Mike Kay is
>    doing with the XSLT document: (
> 
><http://www.w3.org/TR/xslt20/#error-summary>http://www.w3.org/TR/xslt20/#error-summary)). 
>
>    Provide a tagging scheme for testing of grammatical statements, such as
>    the ad-hoc one employed in the XPath/XQuery specifications.
>    Possibly provide markup also for discretionary behavior.
>
>My proposed roadmap:
>
>1. We should find out how many use xmlspec, or anything like it, now. Here 
>group chairs coudl help greatly.
>2. We should play around with the idea of creating an extension to xmlspec 
>(or write it from the beginning) to represent semantics and intended 
>behaviours (again, please include me in the loop)
>3. Any interested party should read the QA Specification Guidelines 
>document, comments are very much appreciated.
>4. The topic of whether the HTML version found on the web or the 
>(generated) XML  version is the normative one should perhaps be made 
>again, as following the idea that originating this thread will certainly 
>mean that the XML version takes precedence over any other version (when it 
>comes to specification interpretation)
>5. Find a relevant forum for discussing this. the QA IG list has been 
>proposed, and I think it may be the right place for it, at least for now.
>
>I think 5 can be dismissed, as it seems that the QA IG list is the place 
>to discuss these issues.
>
>Arguments against uniform and non-optional toolset (a selection amongst 
>the most frequent ones):
>
>1. Added burden (WGs are already overloaded and would need to allocate 
>time to learn a new markup)
>2. No clear benefits
>3. One schema does not fit all specifications
>4. Addressing scheme and specification schema should be separate
>
>What I propose that the QA WG allocate time and (possibly) resources on is:
>
>1. Contact W3C WG chairs to find out what, if any, schema, tools and 
>practices they use to author specs.
>2. Engineer an adressing scheme allowing reference to parts of 
>specifications (sentences, sections, assetions)
>3a Engineer a specification schema allowing expressing assertions and the 
>like
>3b. Come up with an extension to xmlspec to cover the areas above
>3c. Model this information in XHTML using the class attribute
>4. Find the right forum to "sell" this idea once formalized
>
>/Dimitris </blockquote></x-html>