2002/ws/desc/test-suite faq.html,1.2,1.3

Update of /sources/public/2002/ws/desc/test-suite
In directory hutz:/tmp/cvs-serv21379/test-suite

Modified Files:
	faq.html 
Log Message:
updated test suite faq

Index: faq.html
===================================================================
RCS file: /sources/public/2002/ws/desc/test-suite/faq.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -C 2 -d -r1.2 -r1.3
*** faq.html	17 Oct 2006 14:59:35 -0000	1.2
--- faq.html	17 Oct 2006 16:13:51 -0000	1.3
***************
*** 13,16 ****
--- 13,20 ----
  	<li><a href="#what">What is in the test suite?</a></li>
  	<li><a href="#how">How do I contribute a test case?</a></li>
+ 	<li><a href="#xpath-coverage">Which good documents should I
+ 	contribute?</a></li>
+ 	<li><a href="#assertion-coverage">Which bad documents should I
+ 	contribute?</a></li>
  </ul>
  
***************
*** 88,91 ****
--- 92,135 ----
  email instead of just the WSDL 2.0 document.</p>
  
+ <h2><a name="xpath-coverage">Which good documents should I
+ contribute?</a></h2>
+ 
+ <p>We are aiming to have complete coverage of all XML elements,
+ attributes, and enumerated values that can occur in WSDL 2.0 documents.
+ You can see how well the test suite covers these items by looking at the
+ <a
+ 	href="http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/test-suite-coverage-summary.xml?content-type=text/xml">
+ WSDL 2.0 Document Test Case Coverage Report</a>. This report is generated by
+ counting the matches of a list of XPath expressions on each good and bad
+ document. Each XPath expression is assigned a red, yellow, or good
+ status depending on the count. A count of zero corresponds to red
+ status. A positive count of less then four is assigned yellow, and a
+ count of four or more is assigned green. Our first priority is to have
+ no red counts, so start there. Look for XPath expressions that have red
+ status and construct good documents that match. After we get rid of all
+ the reds, we'll focus on the yellows.</p>
+ 
+ <p>Note that this coverage report includes both good and bad
+ documents. However, it is desirable to have good documents that cover
+ all the XPath expressions since these can also serve as examples of
+ correct usage to authors.</p>
+ 
+ <h2><a name="assertion-coverage">Which bad documents should I
+ contribute?</a></h2>
+ 
+ <p>We are aiming to have complete coverage of all testable
+ assertions. This means that for each testable assertion, we need a
+ document that violates it. Look at the <a
+ 	href="http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/assertions-report.html?content-type=text/html;%20charset=utf-8">Assertion
+ Coverage Report</a> to see which assertions are already covered. Red status
+ means no coverage, and green means one or more.</p>
+ 
+ <p>To create a bad document, it is often easiest to start with a
+ good document and then modify it to violate the assertion.</p>
+ 
+ <p>Note that some assertions are optional, in which case the
+ document is good. Optional assertions are suggestions or best practices.
+ They correspond to the keywords SHOULD, SHOULD NOT, and RECOMMENDED in
+ the specification.
  </body>
  </html>

Received on Tuesday, 17 October 2006 16:14:07 UTC