Re: Updated domtest.xsd and simple attr.xml

I have put the following up on my personal home page temporarily, eventually
these will be hosted on xmlconf.sourceforge.net

http://home.houston.rr.com/curta/domtest/domtest.xsd - Schema for DOM tests
(same as the last post)
http://home.houston.rr.com/curta/domtest/domtest.dtd - Automatically
generated DTD from previous schema
http://home.houston.rr.com/curta/domtest/domtest.html - Automatically
generated documentation from schema with graphics
http://home.houston.rr.com/curta/domtest/attr.xml - Trivial example of very
simple test


Dimitris Dimitriadis wrote:

>The more pressing question is if we decide to move along by keeping the two
schemas separate,
>or if we try to use functionality from both. The DOM WG has expressed some
things it would like >to see in the DOM TS ML as given in
http://lists.w3.org/Archives/Public/www-dom-ts/2001Apr/0054.html.

>One remark is that the DOM TSML should be simple enough to develop against,
as well as >understandable by most people in the community. I have a feeling
that most people would not be >able to use your schema to its fullest extent
(given that it's quite advanced).

The "complexity" has to be somewhere, by putting it in the schema or DTD, it
enables schema or DTD-aware editors to guide the user in building the test.
If you just used generic <CALL> elements, then the user is going to have to
guess the supported method names and find their errors when they try to
compile their Java code after doing an XSLT transform.



>Another thing we said when we began writing the DOM TS ML was that it
should be easily >portable to the XUnite framework, in order to let
developers use any framework they wanted. I >haven't had a chance to assert
whether this is the case in the schema you propose.

I designed the schema based on my experience with migrating the NIST DOM
tests to the JUnit, JSUnit, and CppUnit frameworks.  I definitely believe
that it is much more friendly to generating xUnit code than anything else
proposed.

>*** In general, I think it's a better idea to comply with the spec, now
that it's been published as a >recommendation. Until applications start
supporting that, I propose to use the only schema language >(nearly totally
supported), namely DTD. Do you have a DTD verison of your schema we could
>look at?

Link to a generated DTD appears above.  Using only a DTD aware editor will
not check, for instance, that the index argument to the NodeList.item method
is either an integer literal or a variable reference, but it will enforce
all the structural constraints.


>On this point I wonder if it is indeed that difficult to add new
information to the test if it were to >contain non-test info in the single
file: I can imagine an easy interface that allows you to change >author
details without touching the test details, even though they exist in a
single file.

It is definitely possible to place RDF and Dublin Core metadata within the
test element.  For example, SVG defines a metadata <element> for exactly
this purpose.  However, you can't keep all the evolving metadata about the
test within the test definition and since you can't keep all of it there,
why keep any of it there.  It would definitely be fairly straight forward to
write XSLT that ensures that all tests defined in the test definition have
at least minimal metadata in the base RDF file.

Received on Friday, 18 May 2001 20:47:00 UTC