SV: [General] Status?

comments inlined

-----Ursprungligt meddelande-----
Från: Curt Arnold [mailto:carnold@houston.rr.com]
Skickat: den 13 augusti 2001 01:37
Till: www-dom-ts@w3.org
Ämne: Re: [General] Status?


[ca]
>> Some minor notes:
>>
>> I think the package attribute on the <test> and <suite> elements is
>> extraneous and expect to remove it from the generated schemas and DTD's
and
>> ignore it in the transforms.  If you are going to commit
>> tests, you may go ahead and strip it out now.  The package name will be
>> based on the location of the test.
>
> [dd] The location of the test once we've decided it's ready to form part
of
> the suite, I presume?

[dd] (in a different message)
> think separate directories are preferrable, since we may want to build
>suites that consist of different subsets, except if we explicitly remove
the
> files we don't want to use. Provided we can't solve it with another
mechanis
> that is. Can ANT look into xml-files without including them in the build?
I
> realise that would take lots of extra time, but then we could instruct ANT
> to include only tests that have an explicit value on the test "status"
> attribute.

[ca]
I don't believe that you can adequately judge the validity of a test without
being able to run it.  My take is that, at least in the development phase,
every test submitted that is well-formed goes into the CVS, is translated
into appropriate code and can be invoked.

During the review cycle a subset of all submitted tests would developed that
would be the conformance suite.  I don't think it is essential to remove the
rejected tests from the CVS or the build and it would actually better
preserve the history if we left the rejected tests in (but they wouldn't be
run unless you explicitly requested one).

Moving the tests, changing the target URI's or package names would all tend
to break the continuity of the review cycle.

My preference would be that the definition of the test suite be explicit,
that is a <suite> element listing the accepted tests, and that the metadata
about the review process (links to comments on particular tests, approvals
and rejections) be stored externally to the tests.

[dd] OK, sounds OK to me, as long as we decide on one way to go about.


[dd] Definitely. Curt, do you have anything handy on the build process?

[ca] It is more complicated that it should be due to the unreleased state of
Ant 1.4 and problems with either crimson.jar or xalan.jar in the current
nightly build.  I will make an attempt to isolate the issues and make them
known to the Ant team so that they might be able to provide an Ant version
that works out of the box.

The mailing list search is down and I don't have time to find the previous
message that I described everything, but basically the steps are:

1. put patch (part of CVS) and sed (part of most linux distributions and
downloadable from http://www.cornerstonemag.com/sed/sed3028a.zip   for
win32) on the path
2. download a nightly build of ant and the optional tasks jar
3. Remove jaxp.jar, crimson.jar and xalan.jar from the ant /lib directory
and replace with Xalan.jar and xerces.jar from the Xalan 2.1 distribution.

Until there are tests in the CVS, nobody who doesn't have there own test
definitions can building anything, so it is too early to document anything
more than just information emails.  Once we have something buildable in the
CVS, then we can write up an appropriate documentation and hopefully it will
be less messy.

> [dd] Do we solce this if we wrap it in a CDATA section like Fred
indicated?

Using CDATA sections should allow &, < and ?> to appear in CVS commit
comments.  Guess you couldn't put a ]]>< into a CVS commit commit.  Fred and
my take was that there is no harm in adding log elements at a later time and
to defer any action on that.

[dd]
One reason to avoid 8.3 is the test's names as they currently stand, take a
look at the NIST matrix...

Perhaps x.3 is a better way to go if we want to avoid long suffixes.

.domtest would also work, so that's mainly a design issue. I'd go for .tst
personally.

[ca]
I was never intending to try to limit the test name of 8 characters.  I was
trying to explain that by still primarily thinking in terms of three letter
extensions (the 3 part of 8.3), I proposed a extension that might conflict
with the test definitions from some other testing tool and that a longer
file extension might should avoid that potential conflict.

[dd] I realise this, my mail was intended at the .3 as well.

Received on Monday, 13 August 2001 04:35:21 UTC