Re: [Xmlconf-developer] Updated domtest.xsd and simple attr.xml

Dimitris Dimitriadis wrote:

>1. Given that we have a series of issues to discuss, it seems like a good
>idea to have a telephone conference in order to resolve them as quickly as
>possible. I'll get back to the list with details on when this will be. In
>the meanwhile, please indicate if you would be interested in taking part.

Please let me know the details.

>2. I do not have any principal argument against defining elements as
methods
>in the schema (except for the _very_ important time aspect) instead of
>entities as has previously been done. As the DOM TS ML 0.9 is work in
>progress, it would need to be changed in any case. Since we are going to
>change both the schema and the test files themselves, adding another item
to
>the agenda is not that problematic.

I guess this is a problem with the visibility of any work others have done.
If
there is a significant amount of tests encoded in the other markup, then
if someone would somehow make them visible, then maybe we can
transform them appropriately.

>3. I would refrain from putting too much "intelligence" in the DTD/Schema,
>as I want it clean, small and efficient (which I think goes for all of us).
>I seriously do not think that giving developers the ability to have entry
>helpers while writing tests is a good enough argument to make the schema
>more advanced than need be. Presumably, they are confident enough with DOM
>to be able to write tests with the help of the various help documents that
>will form part of the DOM TS as well as the specifications (the help
>documents will be written once we decide on the framework). I think this is
>a fair assumption to make. Please do not forget that the TSML is a
>representational language, not the DOM spec itself.

The less constrained the test language is, then the  more complex the
transformation
layer has to be, or the more likely people will write tests that won't
generate valid
code.

>5. Perhaps given my background I am not in favour of using one language
over
>another (this is relevant for the "using JAVA or IDL to describe tests"
>question). I propose that we use the IDL definitions and accept their
>shortcomings since we want the DOM TS to be language-neutral (as is the DOM

The use of a Java binding like form for property accessors and mutators was
more a reflection of limitations of Schema or DTD validation.  By using
distinct
elements for the accessor and mutator of a property, I can require that
an accessor has both an "obj" and "var" attribute and a mutator has both
a "obj" and "value" attribute and that an accessor doesn't appear in an
<assertDOMException> block if only the mutator throws an exception.

Since there is no support for attribute cocurrence constraints in schema,
if you have an element that represented both an accessor and mutator,
then you would require the "obj" attribute and make the "var" and "value"
attributes optional.

I prefer a pair of get/set elements over a single property element, however
I could tolerate a single property element.

>6. DTD/Schema: No personal preference, but can we demand that developers
use
>implementations with schema support? We could of course use a DTD
>translation of the Schema, but I feel it would lose lots of Schema-specific
>information (especially if we were to involve inheritance and so forth)
>which would not be captured. In that case we would still be on a purely
>syntactical level with no added value.

I don't see that it is necessary to demand anything.  A person could write a
totally
valid test case without using either the schema or the DTD.  However, having
a DTD
or Schema greatly assists in the process.

The only schema specific information lost in the generated is the typing on
the attributes.
So if you use a DTD aware editor against, it won't check, for example, that
you are passing
either an integer literal or variable to the NodeList.item() function.

>Allowing for my possible misreading (in case of which I apologize): Curt,
>are your closing sentences in your email ("I'm going to try to get (a-b)
>done today, (c-e) over the next few days.  As I put things in the xmlconf
>CVS or make releases, I'll announce it on xmlconf-developer but won't on
>www-dom-ts ") in any way indicative of your commitment to work on a single
>solution within the DOM TS framework? Would you rather have two parallel
>frameworks?

I didn't want to pollute the www-dom-ts mailing list with messages that
didn't have a significant long term value.  I believe both you and Mary (and
probably
others) were on both lists, so I was trying to indicate that if someone was
interested
in emails on the process of what I was doing that they should subscribe to
xmlconf-developer.
So far I think I have posted everything to both lists.

Received on Monday, 21 May 2001 10:34:42 UTC