SV: Action item list and agenda for telephone conference

I've inlined my comments below

-----Ursprungligt meddelande-----
Från: Arnold, Curt [mailto:Curt.Arnold@hyprotech.com]
Skickat: den 23 maj 2001 20:51
Till: 'www-dom-ts@w3.org'
Ämne: RE: Action item list and agenda for telephone conference


Just in case, please Be aware that Monday is a 
significant legal holiday in the US.

Here is are some of the issues that I know of:

1. Use of Java binding like accessors and mutators

I'll update the schema to use IDL like accessors and mutators.
There will be some loss of constraint checking but the number
of read-write properties is small.

*** I look forward to reading your schema. Hve you thought about working
towards a common schema or endign up with two?


2. No mechanism for in-line metadata

I would suggest either adding to the content model of <test>,
<suite> and the assertions either a <metadata> element with
a very permissive content model or a <rdf:RDF> element.
However, with the acknowledgement that external metadata
is expected and that in-line metadata should be reserved
for (relatively) fixed metadata (for example, author or source,
not test results for a particular processor)

*** I'm happy either way, as long as we agree. There is in teh NIST proposal
a fixed set of information about the test (not the suite) which covers all
the things you mention. 

As a question, though, what external metadata would be expected? I assumed
that all relevant metadata would be inlined in the test decritpion itself.


3. Test packaging

Suite definition is currently supported by placing test
definitions within <suite> elements.  Preferable to 
have tests as independent XML documents.  I propose
defining <suite> with <test href=".."/> children as
an interim approach but think that we might eventually use EARL
to define test packaging.

*** Independent XML documents is precisely where we wanted to end up.
Packaging the in a suite construct is very straightforward. I look forward
to further discussing the possible use of the EARL framework. Have you
received any feedback from that community?

4. Identifying test documents

I had defined a <document> element to provide some
mechanism for indirection, however that is definitely
inadequate.  I propose switching <load> back to using
a URI to identify the test document but
with the expectation that a mechanism
outside of the test definition (RDDL?) would be used to
resolve the test URI to an local resource.

*** Sure, that could be one way of doing it. I anticipate implementor's
various harnesses to deal with that to the largest possible extent so as not
to burden the DOM TS framework.

5. Lack of usable XML schemas for DCMES and EARL

The XML schema for DCMES seems pretty strange on
a quick read and I'm pretty sure that it is not valid.
I don't know of an XML Schema for EARL.  There is
an (non-normative) XML Schema for RDF on the schema 
home page.

6. Lack of visibility (at least from outside the DOM WG)

I haven't seen the existing XSLT transform for
Java and ECMAScript.  I assume they are against the NIST
DTD and maybe against the NIST testing framework.

Since I'm spending a good deal of personal time on this,
it would be good to have some idea that I'm not replicating
work that is already going on.  It would be very helpful
if people could publicly state at least what they are
thinking about working on or need for their continued
progress.

*** With all due respect, and totally acknowledging your point, I don't
think introducing a radically different framework was the best way to
minimize time invested. In any case, your framework had lots of very good
solutions, so I look forward to our working together in the same direction
(today is actually a holiday where I live, so I've also invested personal
time)


7. Coordination with XML Schema test development

I've pinged the xmlschema-dev list to see if
they could share their approach to test metadata.

*** I did this some time ago, but haven't received any useful information.
Thanks for reminding them, let's just hope that they respond quickly.

Received on Thursday, 24 May 2001 10:36:52 UTC