David:

Correct.  Changed the catalog file to load the correct file.  Please close the
bug if in agreement and able to verify.

Thanks,
Carmelo

It would be helpful, Carmelo, if you could tell us what the correct source file is!

oops sorry.  It is "id.xml".  I will submit a new version of it now.
The one that was released, I am afraid may not be good enough to run the 
tests.  I can e-mail you a copy of it or you can grab it from the
CVS repository.  Should be ready in about 10 minutes.

Carmelo

The id.xml file included in the 0.9.0 distribution is wrong. It contains elements such as

<elementwithidref-1>id1</elementwithidref-1>

where id1 is supposedly an IDREF value; but there is no way of achieving this with a DTD, it can only be achieved with a schema. DTDs only allow IDREF attributes, not IDREF elements. The DTD defines this element as <!ELEMENT elementwithidref-1 (IDREF)> which declares an element that has a child element named IDREF (and doesn't allow #PCDATA content) - this document therefore isn't even valid against the DTD.

Also, the DTD is missing this declaration

<!ATTLIST elementwithid-5
    anId ID #REQUIRED>

Also, it would be helpful if the DTD was defined in an external file.

Another limitation of DTDs is that an element can only have one ID attribute: so

<!ATTLIST elementwithid-4 
    anId3 ID #REQUIRED
    anId4 ID #REQUIRED>    

is not correct

All:

I will turn the file into a schema.

Carmelo

David:

Thanks for the comment.  The "id.xml" was modified to be valid in relation 
to the "id.xsd" schema.  The tests were changed to reflect schema usage. 
New tests (and where required, new results) were submitted.  Catalog file was changed to reflect new inputs.  

Please close the bug in in agreement.  Somehow I think this is not quiet over yet.

Thanks,
Carmelo

Reopening this one.
the tests that now depend on PSVI input (eg fn-idref-5) should be moved to an optional area of the test suite for systems supporting the schema import feature, or (less useful)
alternative expected results should be provided for the case that there are no
nodes of type ID or IDREF in the input (as no DTD is provided).

If the tests are left in the minimal conformance area, and just additional expected result files are provided which typically will be empty as nothing will be selected by id() or idref() then the tests are seriously weekened as a system would "pass" the tests if it just had a stub implementation that always returned ().




David

Dave:

Thanks for the message.  Although I agree with you that adding the extra
outcome can weaken the test somewhat, I will be relutant to just move the tests
as there are others, which use schema and still part of the minimal
area tests.  

Thanks,
Carmelo

It doesn't just weaken them a bit, it really renders them pointless as a system can pass them just by making the functions no-op. 

Where there are multiple output-files supplied then (where it makes sense) there should be an extra attribute in the catalogue saying which kinds of processors should use which
expected result file. So in this case a system supporting psvi input would be required to return the current expected result file, and a system  not supporting psvi input would be required to return an empty result. There should also be some tests testing id/idref based on dtd declarations so that non schema systems also get tested for real implementations of id/idref. Note that supporting psvi input is not the same as supporting the schema import feature.
(Perhaps it should be. XSLT2 for example bans a system  that does not support schmema import from supporting schema type annotations on input)


> I will be relutant to just move the tests
> as there are others, which use schema and still part of the minimal
> area tests.

Which is an architectural bug in the test suite, that "minimal" set of tests requires a feature that is explictly out of scope of the spec. The real fix is just not to do that, masking the problem by providing multiple result files, especially if these are not categorised in any way, is just papering over the cracks.



David (not really as grumpy as the above may indicate)

Dave:

Thanks for the point.  We will look into this issue at the conf call.
Your comments are always welcome.  You provide good feedback.

Carmelo

Just one extra minor detail to add to this sorry tale: in converting the tests to work with a schema, the namespace of the source documents was changed, but the namespace of the result documents was left null. So of course all the results are wrong even if you can get the test working.

Dave:

We discussed your suggestions, but yet decided that it is better to leave the tests where they are and just allow for the alternate results.  We are very much aware of your arguments, but given the nature of fn:id and fn:idref,
a schema seems like a natural for those.

Thanks,
Carmelo

> but given the nature of fn:id and fn:idref,
> a schema seems like a natural for those.

I disagree, sorry.
ID and IDREF have been supported in DTD based products for around 20 years now,
so rather longer than XSD schema has been around. A conforming XQuery system explictly does not need to support XSD schema, but does need to support the core F&O functions relating to ID processing. Given that XSD support in Xquery is an
optional feature, it is wrong to use it to test mandatory features.

David

Dave:

I write a DTD version of the ID/IDREF tests and make them available
from the basic area. 

Carmelo

Thanks, sorry to cause extra work:-)

Its not a problem at all.  Hallf way there already!

Carmelo