W3C home > Mailing lists > Public > www-dom-ts@w3.org > May 2001

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

From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
Date: Fri, 18 May 2001 15:28:03 +0200
Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A64A1@VXOIMP1>
To: "'Curt Arnold'" <carnold@houston.rr.com>, xmlconf-developer@lists.sourceforge.net, www-dom-ts@w3.org
I have a few comments inlined below:
 
As a general remark though: we should try to keep in line with the various
issues that have been raised, on the one hand, but also work together in
order to achieve our common goal, on the other.
 
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
<http://lists.w3.org/Archives/Public/www-dom-ts/2001Apr/0054.html> .
 
Best,
 
/Dimitris

-----Ursprungligt meddelande-----
Från: Curt Arnold [mailto:carnold@houston.rr.com]
Skickat: den 18 maj 2001 08:35
Till: xmlconf-developer@lists.sourceforge.net; www-dom-ts@w3.org
Ämne: [Xmlconf-developer] Updated domtest.xsd and simple attr.xml


I've updated my alternative XML Schema for DOM tests and started writing a
few experimental test in preparation of attempting to convert my
domunit/junit code to XML.
 
*** There are some major differences between your schema and the one used by
NIST and proposed to the mailing list participants as the basis for the DOM
TSML 1.0. I think we can go in two directions: we either set up an agenda of
action items to bring the two closer together, or we decide which one will
form the basis for the DOM TSML. 
 
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).
 
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.
 
You can see a very simple Attr test (parentNodeNull) at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlconf/domunit/DOM1/NIST/att
r.xml?rev=1.2
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlconf/domunit/DOM1/NIST/at
tr.xml?rev=1.2&content-type=text/vnd.viewcvs-markup>
&content-type=text/vnd.viewcvs-markup
 
The updated schema is
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlconf/domunit/domtest.xsd?r
ev=1.2
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/xmlconf/domunit/domtest.xsd?
rev=1.2&content-type=text/vnd.viewcvs-markup>
&content-type=text/vnd.viewcvs-markup  
 
The files comply with the Oct 2000 Schema working draft since that currently
has the best software support.
 
*** 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?
 
 I think it now has enough (or close to enough) constructs to handle the
NIST DOM tests and has elements for all of the DOM 2 Core.
 
On the test metadata, my personal leaning would be to use the Dublin Core
Proposed Recommendation "An XML Encoding of Simple Dublin Core Metadata" (
http://dublincore.org/documents/2001/04/11/dcmes-xml/
<http://dublincore.org/documents/2001/04/11/dcmes-xml/> )  This would keep
the metadata in a distinct file from the test in a format that was
compatible with RDF and provides both a DTD and an attempt at an XML schema
for the metadata.  One of the advantages of keeping the metadata distinct
from the test definitions is that it is then easy to add additional
description, notes, translations, without modifying the test definitions.
 
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.
 
Received on Friday, 18 May 2001 09:28:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:02 UTC