Updated proposal outlined

A URI scheme for the existing staff* files and the NIST/OASIS XML v2 conformance suite would be helpful.  We should probably try to minimize the desire of people to add new test documents to the DOM
test suite.  If there isn't coverage of the structural feature, then it probably should go into the XML conformance suite.  Ideally, the URI's would be resolved against a local copy in a JAR or other
archive.

One of the reasons that I preferred defining the tests in XML Schema and then generating the DTD is that the schema can be used as a resource in the transforms.  The transforms would only need to have
templates for the language elements (the <asserts>, <assigns>, etc).  All the DOM methods could be generated by a generic template that checked the schema for the "type" of the element to determine if
the element was a property accessor, property mutator or function and the order of parameters.  Without obtaining that information from the schema, that has to be replicated in the transforms.

The problem with not explicitly declaring the variables comes on platforms where there is not a common ancestor class (like Object in Java).  If I was converting to C++, then it is really significant
that I can determine that an variable is a String, Node, integer or the like.  Trying to guess the appropriate type really ups the complexity.  XML Schema's <key> and <keyref> could be used to assert
that all var and object parameters were defined.  However, I haven't explored if they are supported by the current schema aware editing tools or whether they can be done in a manner that would be
legal both in Oct 2000 Schema (for compatibility with current tools) and the recommendation.

On case submission, I'd prefer a system where any test submission becomes immediately publicly visible.  Whether it is a good test, unneeded test, or a just plain bad would be decided in the WG in due
time and expressed in RDF.

If a test is hidden until the WG passes judgment on it, then there is not a chance for others to suggest enhancements, raise issues, etc.  Then it has to cycle the WG if there were any issues.

Since you want to basically give the public write access, CVS doesn't seem appropriate since you'd have to give everyone too much power to do damage.  How about something like Manila or SharePoint?
Maybe just in the test collection process.

Received on Friday, 25 May 2001 14:56:14 UTC