OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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