This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
What aspect is prefix-from-qname-8 testing. The description says: (: Description: Evaluation of fn-prefix-fromQName function with a prefix that is not defined. :) The query is as follows: fn:prefix-from-QName(xs:QName("foo:bar")) According to the catalog XPST0003 is expected. We believe this query tests the xs:QName constructor where the prefix in the literal is not declared. As such FONS0004 should be expected. As started in the description, it is unclear what the purpose of this test is. Especially as the current approach doesn't seem to test fn:prefix-from-QName(). Regards, Marc
Marc: Thanks for the comment. Although, I agree the give error code is in correct, it will seems as though "XPST0081" is more appropriate. Please comment. Thanks, Carmelo
No, I believe FONS0004 is the correct one. This query invokes a constructor functions xs:QName, passing it an xs:string "foo:bar". As such the following applies: http://www.w3.org/TR/xquery-operators/#constructor-functions. And here we read: ... The prefix within the lexical xs:QName supplied as the argument is resolved to a namespace URI using the statically known namespaces from the static context. If the lexical xs:QName has no prefix, the namespace URI of the resulting expanded-QName is the default element/type namespace from the static context. Components of the static context are discussed in Section C.1 Static Context ComponentsXP. A static error is raised [err:FONS0004] if the prefix is not bound in the static context. As described in Section 2.1 TerminologyDM, the supplied prefix is retained as part of the expanded-QName value. ... Thanks Marc
Frans: TYhanks for the explanation. Code changed to FONS0004. Please close bug if in agreement. Carmelo
Carmelo, The expected error code in XQTS 0.9.4 is still XPST0003, can it be changed to FONS0004 please. Thanks, Tom.
All: Catalog file changed to reflect FONS0004. Thanks, Carmelo
Issue verified and indeed fixed! Closing. Thanks, Tom.