This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Some of the issues described here might have been reported before (for example in bug 2666), but not being completely sure about that we prefer to submit a new bug. The are a number of tests which still seem to be dependent on XML schema one way or the other. a) tests expecting that schema import is supported b) tests expecting that the PSVI mapping is used As such these tests fail with implementation not supporting schema import or implementing the InfoSet mapping. Here is an example for scenarion a), ForExprType027 (: Name: ForExprType027 :) (: Description: FLWOR expressions with type declaration (attribute type). Wildcard match on user defined simple type on attribute :) (: insert-start :) import schema default element namespace "http://typedecl"; declare variable $input-context external; (: insert-end :) for $test as attribute( *,Enumeration ) in $input-context/root/UserDefinedSimpleTypeAttribute/@att return data( $test ) An implementation not supporting schema import will not recognize the "Enumeration" type. As such it will report an error. An example of scenario b) is ForExprType010: (: Name: ForExprType010 :) (: Description: FLWOR with type expression matching a type from the schema :) declare namespace xqt="http://www.w3.org/XQueryTestOrderBy"; (: insert-start :) declare variable $input-context external; (: insert-end :) for $num as xs:decimal in data( $input-context/xqt:DataValues/xqt:NegativeNumbers/xqt:orderData ) return $num An implementation based on the InfoSet mapping will raise an error. The result of fn:data is an xs:untypedAtomic instance and will thus result in err:XPTY0004 Other examples of this b) sceanrio are the tests where a QName is assumed to be retrieved out of a document. Take for example LocalNameFromQNameFunc001 (: Name: LocalNameFromQNameFunc001 :) (: Description: Test function fn:local-name-from-QName. Using QName element as input :) declare default element namespace"QNameXSD"; (: insert-start :) declare variable $input-context external; (: insert-end :) fn:local-name-from-QName(($input-context/root/elemQN)[1]) Basically the scenario here is as follows: - the argument of the local-name-from-QName function is a xs:untypedAtomic("ns:bar") - by the function conversion rules this xs:untypedAtomic is converted to an xs:QName. - But, the prefix "ns" is not declared in the query's static context. As such an error is raised. Here is he list of tests for which an expected error should be added 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 Constr-compattr-compname-9 Constr-compelem-compname-9 Thanks, Marc
Here are 2 additional tests Constr-cont-constrmod-4 Constr-cont-constrmod-8 For both tests it is assumed that the xs:decimal 12678967.543233 can be casted into an xs:integer. But in case of InfoSet mapping this casts xs:untypedAtomic("12678967.543233") into an xs:integer. This fails with FORG0001. In addition to the successful result, this error code should be added as expected error code.
Marc: Thanks for the comment. These are mostly Microsoft tests. Assigning bug to Jinghao. Thanks, Carmelo
I notices a test is missing in comment #1. Also Constr-compelem-constrmod-8 has a similar issue. Thanks, Marc
I have 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
We justed checked XQTS_current.zip v1.25 and it seems two issues are not resolved yet: 1. FORG0001 ----------- We still believe the following tests should allow a FORG0001 as result: Constr-compelem-constrmod-8 Constr-cont-constrmod-4 Constr-cont-constrmod-8 2. Moved tests -------------- As far as we can see the following tests were not yet moved to the optional features area: ForExprType010 LocalNameFromQNameFunc001 LocalNameFromQNameFunc002 LocalNameFromQNameFunc003 LocalNameFromQNameFunc004 LocalNameFromQNameFunc018 LocalNameFromQNameFunc019 LocalNameFromQNameFunc020 NamespaceURIFromQNameFunc001 NamespaceURIFromQNameFunc002 NamespaceURIFromQNameFunc003 NamespaceURIFromQNameFunc004 NamespaceURIFromQNameFunc018 NamespaceURIFromQNameFunc019 NamespaceURIFromQNameFunc020 All the other tests mentioned before are indeed moved... Thanks, Tom.
I've just made the following changes: Modified these test cases to work on a constructed xs:QName value: Constr-compattr-compname-9 Constr-compelem-compname-9 Allow FORG0001 for implementations that operate on input documents that have not been validated: Constr-compelem-constrmod-8 Constr-cont-constrmod-4 Constr-cont-constrmod-8 I believe that others have already addressed the other test cases that have identified in this bug report. Please mark this bug report as closed if you agree with our resolution.
Unfortunatelly in XQTS_current.zip rev 1.33 the tests mentioned in the second part of comment number 5 have not been moved. Forgive me the 'noise' if I overlook something. An InfoSet-based implementation will raise an error for these tests (2nd point in comment number 5). a) ForExprType010 XPTY0004 is reported as the sequence type matching of an xdt:untypedAtomic instance with xs:decimal fails b) LocalNameFromQNameFuncXXX and NamespaceURIFromQNameFuncXXX LocalNameFromQNameFunc001 LocalNameFromQNameFunc002 LocalNameFromQNameFunc003 LocalNameFromQNameFunc004 LocalNameFromQNameFunc005 LocalNameFromQNameFunc018 LocalNameFromQNameFunc019 LocalNameFromQNameFunc020 NamespaceURIFromQNameFunc001 NamespaceURIFromQNameFunc002 NamespaceURIFromQNameFunc003 NamespaceURIFromQNameFunc004 NamespaceURIFromQNameFunc005 NamespaceURIFromQNameFunc018 NamespaceURIFromQNameFunc019 NamespaceURIFromQNameFunc020 Something has been modified in these tests, see also bug #3534, but still are failing (XPTY0004) with an InforSet based XQuery implementation. Recently explicit xs:QName constructors have been added to these queries. In http://www.w3.org/TR/xquery/#id-constructor-functions we read: The constructor functions for xs:QName and for types derived from xs:QName and xs:NOTATION require their arguments to be string literals or to have a base type that is the same as the base type of the target type; otherwise a type error [err:XPTY0004] is raised. In these tests the argument of xs:QName is not a string literal. And with InfoSet-based implementation the argument is also not an instance of xs:QName. As such this results in XPTY0004. Thanks, Marc
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3534 seems to duplicate this one and is resolved. I've updated XQTS_current.zip, so if the resolution of #3534 is satisfactory, XQTS_current.zip should have it. Marc, you're welcome to try out the latest XQTS_current.zip and comment on any findings. Frans
Well, maybe I'm misunderstanding soemthing, please explain, I'm more than willing to listen. When I reported the issue earlier today the latest revision of xquery-test-suite/PublicPagesStagingArea/XQTS_current.zip was 1.33, but just double checked and believe it is the same in today's 1.34. I cannot judge if the resolution #3534 is applied to XQTS_current.zip and whether it duplicates this bug. Still, I believe there are a number of tests which are not InfoSet-mapping savvy. As an example, let's take the first test listed in http://www.w3.org/Bugs/Public/show_bug.cgi?id=3276#c7. ForExprType010: for $num as xs:decimal in data( $input-context/xqt:DataValues/xqt:NegativeNumbers/xqt:orderData ) return $num An implementation which is InfoSet-based reports XPTY0004 as an xs:untypedAtomic is not sequence type matching compatible with xs:decimal. It's ok with me if XPTY0004 is added as an expected error, but I'm of course open for other suggestions. The issue with the other listed queries in http://www.w3.org/Bugs/Public/show_bug.cgi?id=3276#c7 is different, but are also failing with an InfoSet-based implementation. Thanks, Marc
Ok, we talked this through offline with Andrew Eisenberg and Funda Ertunc. And got clarification on our misunderstanding. There was no reason to reopen this bug (see note number 7). Marking the bug as resolved.