- From: Dimitris Dimitriadis <dimitris.dimitriadis@improve.se>
- Date: Fri, 18 May 2001 15:28:03 +0200
- To: "'Curt Arnold'" <carnold@houston.rr.com>, xmlconf-developer@lists.sourceforge.net, www-dom-ts@w3.org
- Message-ID: <9F67DC27F4CCD311ABA600508B6A66A44A64A1@VXOIMP1>
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