RE: /* undeclared */ on declared variables

I've fixed test-to-java.xsl to eliminate the problem.  The parameter type was wrong and the value type was missing on a template call to generate arguments for property mutators.  Since things were seriously wrong the template hoped for the best and emitted the warning and the raw parameter value.

There were a decent number of problems with the DOMBuilderTest1 that schema validation uncovered (once I fixed some issues with schema generation).  I've attached modified copies of DOMBuilderTest1.xml and dom3tests.ent.  The problems were:

short and String were used for type parameter of var elements.  I added short to the list of supported datatypes and changed String to DOMString in the tests.

<var> elements must appear before any other statements in the body of the test.

changed the spec attribute of <subject> to resource.

Added SYSTEM 'dom3.dtd' to the document type declaration.  MSV would not schema validate with a document type declaration but without definitions for all the encountered elements.

Changed the id attributes on assert statements to meaningful unique values.  The assertion IDs are intended to cross reference test failures back to specific assertion statements.

dom-to-xsd.xsl and dom-to-dtd.xsl would produce the readonly form of an property element when there was at least one use of the property name that was readonly.  This resulted in systemId not having a value attribute since there was one readonly form in addition to the read/write use in DOMInputSource.  I changed to tests so the readonly form is only emitted when all uses of the property name are read-only.

I added Jeroen's dom3-gen-java and dom3-javac targets to allow quick iterative code generation.  I would suggest trying to find better names for them since they are confusing with the targets that are used for full rebuilds.

I had hoped to avoid DTD production for Level 3 since there were a decent number of complications that did not affect schema generation.  However, use of external entities in the L3 tests requires (at least for MSV as of 2002-04-14) a DTD before schema validation could proceed.  The DTD produced by dom3-dtd contains multiple declarations for some elements, but is sufficient to let MSV proceed to schema validation.  To check tests, run dom3-dtd at least once to get a copy of dom3.dtd into the tests/level3/ls directory and run dom3-schema to get dom3.xsd into the build directory and then

java -jar msv.jar build/dom3.xsd tests/level3/ls/*.xml