[Bug 9183] [XPath 2.1] Dynamic invocation of xs:QName or xs:NOTATION constructor functions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9183


John Snelson <john.snelson@oracle.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.snelson@oracle.com




--- Comment #1 from John Snelson <john.snelson@oracle.com>  2010-03-24 13:04:53 ---
I propose the following changes to address this bug, to be read in the light of
my proposed changes for the static context of a function item literal from bug
#9139 comment #14:

>From XPath 2.1 section 3.12.2 "Cast", remove:

<remove>
If the target type of a cast expression is xs:QName, or is a type that is
derived from xs:QName or xs:NOTATION, and if the base type of the input is not
the same as the base type of the target type, then the input expression must be
a string literal [err:XPTY0004].
Note:
The reason for this rule is that construction of an instance of one of these
target types from a string requires knowledge about namespace bindings. If the
input expression is a non-literal string, it might be derived from an input
document whose namespace bindings are different from the statically known
namespaces.
</remove>

>From XPath 2.1 section 3.12.3 "Castable", remove:

<remove>
Note:

If the target type of a castable expression is xs:QName, or is a type that is
derived from xs:QName or xs:NOTATION, and the input argument of the expression
is of type xs:string but it is not a literal string, the result of the castable
expression is false.
</remove>

>From XPath 2.1 section 3.12.4 "Constructor Functions", remove:

<remove>
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. This rule is consistent with the semantics of
cast expressions for these types, as defined in 3.12.2 Cast.
</remove>

>From F&O 1.1 section 17.2 "Constructor Functions for xs:QName and xs:NOTATION",
remove:

<remove>
Conversion from an xs:string to a value of type xs:QName, a type derived from
xs:QName or a type derived from xs:NOTATION is permitted only if the xs:string
is written as a string literal. This applies whether the conversion is
expressed using a constructor function or using the "cast as" syntax. Such a
conversion can be regarded as a pseudo-function, which is always evaluated
statically. It is also permitted for these constructors and casts to take a
dynamically-supplied argument in the normal manner, but as the casting table
(see 18.1 Casting from primitive types to primitive types) indicates, the only
arguments that are supported in this case are values of type xs:QName or
xs:NOTATION respectively.
</remove>

>From F&O 1.1 section 18.1.1 "Casting from xs:string and xs:untypedAtomic",
change:

<quote>
Casting is permitted from xs:string and xs:untypedAtomic to any primitive
atomic type or any atomic type derived by restriction, except <remove>xs:QName
or </remove>xs:NOTATION. Casting to xs:NOTATION is not permitted because it is
an abstract type.
</quote>

<remove>
Casting is permitted from xs:string literals to xs:QName and types derived from
xs:NOTATION. If the argument to such a cast is computed dynamically,
[err:XPTY0004]XP is raised if the value is of any type other than xs:QName or
xs:NOTATION (including the case where it is an xs:string). The process is
described in more detail in 17.2 Constructor Functions for xs:QName and
xs:NOTATION.
</remove>


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 24 March 2010 13:04:54 UTC