2903 2006-02-20 23:29:34 +0000 fn-idref-xx incorrect input specified 2006-08-09 10:00:19 +0000 1 1 1 Unclassified XML Query Test Suite XML Query Test Suite 0.9.4 PC Windows XP CLOSED FIXED P2 normal --- 1 davidc carmelo amassari oldest_to_newest 8341 0 davidc 2006-02-20 23:29:34 +0000 fn-idref-5 is specified as taking emptydoc as input-context1 but is specified as generating a non-empty result. I fail all the following for probably the same reason fn-idref-5 fn-idref-6 fn-idref-7 fn-idref-8 fn-idref-9 fn-idref-10 fn-idref-11 fn-idref-12 fn-idref-13 fn-idref-14 fn-idref-15 fn-idref-16 fn-idref-17 fn-idref-18 fn-idref-19 fn-idref-20 fn-idref-21 8570 1 carmelo 2006-03-06 15:42:47 +0000 David: Correct. Changed the catalog file to load the correct file. Please close the bug if in agreement and able to verify. Thanks, Carmelo 8629 2 mike 2006-03-08 16:31:47 +0000 It would be helpful, Carmelo, if you could tell us what the correct source file is! 8656 3 carmelo 2006-03-09 19:21:00 +0000 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 9486 4 mike 2006-04-27 08:17:07 +0000 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. 9568 5 amassari 2006-05-03 13:20:18 +0000 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. 9569 6 amassari 2006-05-03 13:22:19 +0000 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 9582 7 carmelo 2006-05-03 19:16:17 +0000 All: I will turn the file into a schema. Carmelo 9789 8 carmelo 2006-05-15 20:19:49 +0000 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 9986 9 davidc 2006-06-13 12:11:30 +0000 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 9992 10 carmelo 2006-06-13 14:38:11 +0000 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 9994 11 davidc 2006-06-13 15:03:30 +0000 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) 10012 12 carmelo 2006-06-13 19:00:14 +0000 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 10128 13 mike 2006-06-19 20:00:30 +0000 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. 10167 14 carmelo 2006-06-20 17:21:29 +0000 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 10185 15 davidc 2006-06-21 10:08:15 +0000 > 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 10222 16 carmelo 2006-06-23 14:33:00 +0000 Dave: I write a DTD version of the ID/IDREF tests and make them available from the basic area. Carmelo 10223 17 davidc 2006-06-23 14:41:54 +0000 Thanks, sorry to cause extra work:-) 10224 18 carmelo 2006-06-23 15:23:38 +0000 Its not a problem at all. Hallf way there already! Carmelo