7353 2009-08-17 18:45:47 +0000 [XSLT 2.0] Handling an atomic value of type other than xs:string, xs:anyURI or xs:untypedAtomic with the document function 2010-07-15 16:54:44 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 2.0 Recommendation All All CLOSED FIXED http://www.w3.org/TR/xslt20/#document P2 normal --- 1 zongaro mike tim public-qt-comments oldest_to_newest 26493 0 zongaro 2009-08-17 18:45:47 +0000 The signatures of the document function in section 16.1 of XSLT 2.0[1] are document($uri-sequence as item()*) as node()* document($uri-sequence as item()*, $base-node as node()) as node()* The first bullet in that section describes the behaviour of the function if an item in $uri-sequence is of type xs:string, xsl:anyURI or xs:untypedAtomic. It does not indicate what should happen if an item is an atomic value of any other type. The second bullet indicates that if $uri-sequence is a node, it is atomized, and every item in the atomized sequence MUST be of type xs:string, xsl:anyURI or xs:untypedAtomic. In XSLT 1.0, if the first argument to the document function was not a node, it was converted to string as if by a call to the string function.[2] If that was the intended behaviour in the case of an atomic value of a type such as xs:boolean, that needs to be explicitly stated. If it was intended to be an error, that should be stated as well, and the incompatibility noted in appendix J.1.4. As for a node whose typed value contains items of types other than the three mentioned, it seems clear that that is expected to be a type error, but the required error code is not mentioned by the second bullet. [1] http://www.w3.org/TR/xslt20/#document [2] http://www.w3.org/TR/xslt#function-document 35674 1 mike 2010-05-13 16:49:59 +0000 Proposal is to throw XPTY0004 if the value (after atomization if necessary) is not a sequence consisting entirely of xs:string, xs:anyURI, and xs:untypedAtomic values. This resolution is agreed in principle subject to detailed text. 35937 2 mike 2010-06-03 13:02:12 +0000 *** Bug 9842 has been marked as a duplicate of this bug. *** 36888 3 mike 2010-07-15 08:48:18 +0000 Erratum 41 will be raised to implement the decision in comment #1. 36928 4 zongaro 2010-07-15 16:54:44 +0000 Thanks!