Re: Updated domtest.xsd and simple attr.xml

When I first looked at  defining tests in XML, I thought that schemas were
probably the way to go.
I have a very limited knowledge of schemas, so I was reluctant to go down
that path.
Let me say upfront that I believe that what is important here is the ability
to automatically
generate tests for a specific binding.  Both approaches will get us to that
end goal -- assuming
we can take the schema approach and develop an appropriate stylesheet for
it.  I don't mind
Curt's approach of using DOM structures as names, and automatically
generated documentation
is always a plus!

I do have a couple of questions.

1)  For the Document interface, it appeared that the following were missing:

        doctype
        documentElement
        createCDATASection
        createComment
        createDocumentFragment
        createElement
        createProcessingInstruction
        createTextNode

        getElementById (maybe a typo -- I saw getElementsById)
        implementation  (should this be Document.implementation)?

I just looked at the Document interface -- there may very well be others.
Is this schema
possibly still in process?

2)  What are you using as names for the methods and attributes -- the IDL
names, the java
binding, or something else?  This becomes important particularly for the
attributes -- they
are defined as get/set methods in java, and as attributes in ECMAScript.
Differences are
either handled here, or will have to be handled in the transformation, and
was the primary
reason for using IDL names as entity references in the other approach.
Doing so with a
conditional include allowed for the automatic substitution of
binding-specific names.  I don't
mind doing it another way -- do you have something else in mind?

3)  Would it be possible to make use of inheritance for your
attribute/method declarations?
I would think that this would be an advantage that schemas could provide
over a DTD
approach?  I don't currently see attributes and methods defined for
inherited interfaces.  For
example, Text should inherit everything from CharacterData, which in turn
should inherit
everything from Node.

I'm not sure if I have mentioned that we have added about 200 tests to the
the collection
of NIST tests and I expect that about another 200 will have to be written to
fully cover
DOM Level 2 -- we have covered namespaces, errata, and exceptions, but have
not
fully accounted for inherited attributes/methods.  In a couple of days, I
should be finished
with a proposed list of tests for all interfaces, with a mapping of the NIST
tests.  We
can then identify any holes and will be ready to write additional tests.  I
would like to
use the TSML for this purpose.

--Mary

Mary Brady
NIST, Web Technologies
mbrady@nist.gov

----- Original Message -----
From: "Curt Arnold" <carnold@houston.rr.com>
To: "Dimitris Dimitriadis" <dimitris.dimitriadis@improve.se>;
<xmlconf-developer@lists.sourceforge.net>; <www-dom-ts@w3.org>
Sent: Friday, May 18, 2001 8:46 PM
Subject: 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 Saturday, 19 May 2001 12:59:29 UTC