[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Test suite for RELAX NG DTD compatibility spec.
> I agree to have typical ones like <title> or <documentation> explicit, > but <header> is very useful by itself. So I want to keep that, too. > > For example, depending on the situation, I sometimes exclude some of the > test cases. I'd like to use meta information in the header for this. I agree that the set of metadata elements needs to be extensible, but I still don't think we need header to get this. For example, we can do what we do in RELAX NG and allow arbitrary namespaced qualified elements. > As for explicit metadata elements, I'd like to propose <title> (or > <name>), which is supposed to have a short string that represents its > name. I think <author> would be useful as well. I noticed you have a metadata element for saying whether it depends on a XML Schema namespaces. How about something like <requires datatypeLibrary="http://..."/> Any others? >> - I made resources local to each test case, and made the directory >> structure explicit > > Some of my test cases share a common resource between test cases. So I'd > appreciate if we can keep resources a bit more reusable. I think that's an over optimization. It makes test suites harder to maintain and harder to understand. I think it is highly desirable to be able to make each testCase self-contained. It's also not a very effective optimization in my experience: I have found it much more common for instances to be common between test cases than external resources. > I guess we can make resources <testSuite>-local; resources can be > written only under <testSuite> and test cases directly contained in that > test suite can reference them. In this way, when we extract files into a > directory structure, one test suite can go into one directory and > everything will work file. Allowing resources both in <testCase>s and in <testSuite>s would make things rather complicated. > Also, how do you use <dir> in resources? Is this necessary? Are you > using it to test the xml:base handling? <testCase> <section>4.6</section> <documentation>Same value of href before resolution, but not a loop.</documentation> <correct> <externalRef xmlns="http://relaxng.org/ns/structure/0.9" href="sub/x"/> </correct> <dir name="sub"> <resource name="x"> <externalRef xmlns="http://relaxng.org/ns/structure/0.9" href="sub/x"/> </resource> <dir name="sub"> <resource name="x"> <element xmlns="http://relaxng.org/ns/structure/0.9" name="foo"> <empty/> </element> </resource> </dir> </dir> <valid> <foo/> </valid> <invalid> <bar/> </invalid> </testCase> Using dir has two advantages: - it avoids having an attribute whose value is restricted to a relative URI; this just feels wrong to me - it makes it slightly easier to create the necessary directories if you split the test suite into separate files James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC