This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15650 - Introduce schema test-construction rules in XSTS schema document?
Summary: Introduce schema test-construction rules in XSTS schema document?
Status: NEW
Alias: None
Product: XML Schema Test Suite
Classification: Unclassified
Component: XSTS Schema (show other bugs)
Version: 2006-11-06
Hardware: PC Windows 3.1
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: needsAgreement
Depends on:
Blocks:
 
Reported: 2012-01-20 20:18 UTC by C. M. Sperberg-McQueen
Modified: 2012-12-04 00:54 UTC (History)
1 user (show)

See Also:


Attachments

Description C. M. Sperberg-McQueen 2012-01-20 20:18:28 UTC
In June 2010 [1], Mary Holstege recommended 

(1) specifying clearly, in the XSTS documentation, how the schemaDocument elements in the metadata and the schema documents in the actual test suite should relate,

(2) adding some specific instructions for the construction of new test cases (use distinct namespaces, don't use http schema locations, etc.)

(3) adding a method for characterizing schema-location handling in processors.

As of today, the documentation and instructions she suggested have not been added to the XSTS schema document [2] (which is currently the closest thing we have to detailed technical documentation for the text suite).  Should they be?  If we decided this question earlier, we need a bug to remind us to make the change. If we didn't decide it earlier, we should decide it now.

Since the document changes in (1) and (2) seem different from the schema changes in (3), I'm opening this bug for (1) and (2) and another bug for (3).

[1] https://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2010Jun/0007.html
[2] http://www.w3.org/XML/2004/xml-schema-test-suite/AnnotatedTSSchema.xsd
Comment 1 David Ezell 2012-02-24 17:05:50 UTC
From the telcon, from Mary's email at [1] in the bug report:
star 1 - accept
star 2 - overtaken (we use 'known-token'), but ignore/follow should be added to our list of implementation defined behaviors.
star 3 - ok, but needs more discussion.