This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
this is really a continuation of bug #1997, but there are still cases where the supplied result files assume schema validated input. for example LocalNameFromQNameFunc001.xq if the input has not been validated the function will generate an error as you can't cast the untyped input to a QName as required input to the function. Many of the tests in that test group have the same problem. David
David: I will look into this. Carmelo
(In reply to comment #1) > David: > > I will look into this. > > Carmelo Thanks, I think that the following tests show this problem in one form or another. Comp-notation-2 Constr-cont-constrmod-2 Constr-cont-constrmod-4 Constr-cont-constrmod-6 Constr-cont-constrmod-8 Constr-compelem-compname-9 Constr-compelem-constrmod-2 Constr-compelem-constrmod-4 Constr-compelem-constrmod-6 Constr-compelem-constrmod-8 Constr-compattr-compname-9 Constr-docnode-constrmod-2 Constr-docnode-constrmod-4 ForExprType022 ForExprType023 ForExprType024 ForExprType025 ForExprType026 ForExprType027 ForExprType036 ForExprType037 ForExprType038 ForExprType039 ForExprType040 ForExprType041 ForExprType042 ForExprType043 ForExprType044 ForExprType048 ForExprType049 ForExprType050 ForExprType051 ForExprType052 ForExprType053 orderBy25 orderBy27 orderBy57 casthcds2 casthcds8 casthcds9 casthcds10 casthcds13 casthcds14 casthcds23 LocalNameFromQNameFunc001 LocalNameFromQNameFunc002 LocalNameFromQNameFunc003 LocalNameFromQNameFunc004 LocalNameFromQNameFunc018 LocalNameFromQNameFunc019 LocalNameFromQNameFunc020 NamespaceURIFromQNameFunc001 NamespaceURIFromQNameFunc002 NamespaceURIFromQNameFunc003 NamespaceURIFromQNameFunc004 NamespaceURIFromQNameFunc018 NamespaceURIFromQNameFunc019 NamespaceURIFromQNameFunc020 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
David: Thanks for the list. It will be a while before I get to them all. Carmelo
David: I looked at the NIST test and either: 1) You may ignore the schema import statement as the results are not affected by usage of schema. 2) Some of the tests use a new testing approach as suggested by Michale Kay in a different Bug. (casthcds2,casthcds8,casthcds10,casthcds13, casthcds14,casthcds23). Assigning the bug to Microsoft for them to work on their tests. Thanks, Carmelo
(In reply to comment #4) > David: > > I looked at the NIST test and either: > 1) You may ignore the schema import statement as the results > are not affected by usage of schema. > Sorry about that. My test harness always ignores the schema import (or at least makes it into a namespace decln) but if it then fails a test that has a schemaimport it flags it as a test that has an uncatalogued dependence on schema import (or PSVI input) and that automatically generated list is the one I posted. I'm not sure exact;y which are "NIST tests" but I just noticed orderby25 has your name in the catalogue so I rechecked that one and I agree it looks fine to me. Hmm that means there must be another reason that I'm failing the test, such as my code being broken, oh well something to keep me busy over easter... David
just to confirm the inclusion of orderby25 in my list in this report was spurious, sorry. It does use a schema import and I do fail it but that wasn't the reason. It's the xs:float(-0) issue reported in bug #2936, so hopefully this one will pass once the next version of the test suite comes out.
I have verified all Microsoft tests. They all get the same results without schema. Thus no issue.
Dave: The issue should go away as well with bug 2396. I will mark this as fixed once more. Thanks, Carmelo
This was marked as resolved fixed but most of the tests appear to be unchanged in 9.0 for example ForExprType025.xq still has for $test as attribute(*,xs:decimal) which clearly can only work as intended if the input document is input from a PSVI. As stated in earlier bug reports and in the initial comment in this one, it's not just the explict "schema import" that causes dependence on a schema aware system, but assumption that the input has been schema validated. I assume that this is a "Microsoft Test" so comment #7 appears to be in error, so I have reopened the report. see also bug #3276 David
David: That is correct. Jinghao, do you mind re taking a second look at this? Thanks, Carmelo
since there doesn't seem to have been any movement on this report for a while I thought I'd give further details and possible solutions on just one of the affected tests, Constr-cont-constrmod-4.xq similar comments will apply to the other tests. Constr-cont-constrmod-4.xq has import schema namespace atomic="http://www.w3.org/XQueryTest"; In all cases where this appears in the minimal conformance area of the test suite it's essentially a bug just waiting to happen. Either the schema import is really needed, in which case the test should be in the optional schema import area, or the test can proceed just with a namespace declaration, in which case the test should just have that, rather than make the test harnesses make that change, or, as in this case, the import is just spurious and can be deleted, as the query doesn't use any types or element definitions from the atomic: namespace in a query expression. If the schema import is changed to a namespace declaration as allowed by the test guidelines then the expected result is not generated if the input is not derived from a PSVI as you get FORG0001: Cannot convert string "12678967.543233" to an integer As in other places, the catalogue could add the expected error but that as always greatly weakens the test as it means that the actual feature that the test is purporting to test is not being tested at all. It's not really clear what this test is testing as it's a strange mix of element construction modes and atomic type coercions, and the description in the catalogue and the comments are rather terse. So I'm not really sure what to suggest but deleting the schema import and adding an explicit coersion to xs:decimal means that the Expected result is obtained, so perhaps I could suggest: (: insert-start :) declare variable $input-context external; (: insert-end :) <elem>{$input-context//*:decimal}</elem>/*/xs:decimal(.) cast as xs:integer
Ups! It was not my intention to resolve this bug. Changing status to REOPENED. I blame a lot of things for this annoying mistake: the weather(good or bad, both will do), and that Denmark didn't qualify for the world cup. Again, sorry for the noise. Frans
using the july 10 version of xqts_current.zip the number of tests with schema related problems reported by xq2xsl is now down to Comp-notation-5 Comp-notation-8 Comp-notation-10 Comp-notation-11 Comp-notation-12 Comp-notation-13 Comp-notation-14 Comp-notation-19 Comp-notation-20 Comp-notation-21 Constr-cont-constrmod-4 Constr-cont-constrmod-8 Constr-compelem-compname-9 Constr-compattr-compname-9 ForExprType025 ForExprType026 ForExprType027 ForExprType038 ForExprType039 ForExprType040 ForExprType041 ForExprType042 ForExprType043 ForExprType044 ForExprType049 ForExprType050 ForExprType051 ForExprType052 ForExprType053
(In reply to comment #13) In addition to the list in comment #13, LocalNameFromQNameFunc001.xq and all its siblings also have this problem, as originally mentioned in comment #0 (LocalNameFromQNameFunc00x no longer uses schema import, so my test harness just "fails" this without flagging it as a possible PSVI problem, hence these were not listed in the list on comment #13) David
Another test is qname-cast-1, I think.
For the following group: Comp-notation-5 Comp-notation-8 Comp-notation-10 Comp-notation-11 Comp-notation-12 Comp-notation-13 Comp-notation-14 Comp-notation-19 Comp-notation-20 Comp-notation-21 qname-cast-1 The schema import is critical to the test and thus required. I can move this tests to one of teh schema areas and keep both notations on teh catalog. This will ensure the coverage is not lost with the move. Thanks, Carmelo
I plan to do the same for ForExprType025 ForExprType026 ForExprType027 ForExprType038 ForExprType039 ForExprType040 ForExprType041 ForExprType042 ForExprType043 ForExprType044 ForExprType049 ForExprType050 ForExprType051 ForExprType052 ForExprType053 What I plan to do is just updating XQTSCatalog.xml file to move those tests under 2 Optional Features -> 2.7 FOR Clause with TypeDeclaration.
I have moved following test under Optional Features. ForExprType025 ForExprType026 ForExprType027 ForExprType038 ForExprType039 ForExprType040 ForExprType041 ForExprType042 ForExprType043 ForExprType044 ForExprType049 ForExprType050 ForExprType051 ForExprType052 ForExprType053
(In reply to comment #18) > I have moved following test under Optional Features. Where has this change happened? XQTSCatalog has not changed in the public cvs http://dev.w3.org/cvsweb/2006/xquery-test-suite/TestSuiteStagingArea/XQTSCatalog.xml it makes it difficult if the report is marked fixed before the original reporter has a chance to see the change. Also while comment #16 and comment #18 list some of the files for which the problem occurs, that still leaves several more, see for example comment #11 so I've re-opened the report (for the 3rd time, sadly). David
(In reply to comment #16) > For the following group: > qname-cast-1 > > qname-cast-1 doesn't use the schema import, the import schema declaration could just be deleted without affecting the test. it would be good to keep qname-cast-1 (without the schema import) in the minimal conformance section as it is a direct test of the outcome of bug #2678 (which is why xq2xsl and saxon currently fail it as they still follow the CR rule that only string literals could be cast to xs:QName) qname-cast-2 on the other hand does make essential use of schema import since it uses a schema defined derived type. This should be in the optional section of the test suite.
further comments on Constr-compattr-compname-9 Firstly one of the expected result files Constr-compattr-compnamealt-9.xml can not be generated by XQuery at all as it is not namespace well formed, using an attribute atomic:aQName with an undeclared prefix. This expected result should be deleted (and removed from the catalogue). If the schema import is changed to a namespace declaration declaring the namespace for atomic: then an error XQDY0074 will be generated on an undeclared prefix. the test can proceed if instead of the schema declaration the test has a namespace declaration for foo as http://www.example.com/foo and then the expected result is obtained (whether or not the system is schema-aware). David
(In reply to comment #14) > (In reply to comment #13) > In addition to the list in comment #13, LocalNameFromQNameFunc001.xq and all > its siblings also have this problem, as originally mentioned in comment #0 > (LocalNameFromQNameFunc00x no longer uses schema import, so my test harness > just "fails" this without flagging it as a possible PSVI problem, hence these > were not listed in the list on comment #13) > > David > NamespaceURIFromQNameFunc001 and siblings similarly still have schema dependencies (but no longer have explict schema import which is why they are listed in comment #2 but not comment #13)
I checked the change into old cvs place. Sorry. This time I moved all following tests under Optional Features: ForExprType010 ForExprType025 ForExprType026 ForExprType027 ForExprType038 ForExprType039 ForExprType040 ForExprType041 ForExprType042 ForExprType043 ForExprType044 ForExprType049 ForExprType050 ForExprType051 ForExprType052 ForExprType053 LocalNameFromQNameFunc001 LocalNameFromQNameFunc002 LocalNameFromQNameFunc003 LocalNameFromQNameFunc004 LocalNameFromQNameFunc018 LocalNameFromQNameFunc019 LocalNameFromQNameFunc020 NamespaceURIFromQNameFunc001 NamespaceURIFromQNameFunc002 NamespaceURIFromQNameFunc003 NamespaceURIFromQNameFunc004 NamespaceURIFromQNameFunc018 NamespaceURIFromQNameFunc019 NamespaceURIFromQNameFunc020