[Bug 7860] New: [XPath 2.1] Union type as declared function argument

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

           Summary: [XPath 2.1] Union type as declared function argument
           Product: XPath / XQuery / XSLT
           Version: Recommendation
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XPath 2.1
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


This requirement arises because there are various functions in XSLT, such as
key() and format-number(), which take a lexical QName as an argument, and we
have been considering how to allow them to take a value of type xs:QName
instead. We want to do this for a number of reasons, one of which is the
introduction of an xsl:evaluate instruction to allow dynamic construction of
XPath expressions: it is desirable that such expressions should have no
dependencies on the in-scope namespace prefixes. We discussed this in the XSL
WG on 2009-10-08 and I am raising the requirement here as a result of an action
from that meeting.

We could change these functions to declare the argument as xs:anyAtomicType,
but that reduces type safety unnecessarily. The prefered solution is to declare
the type as a union of xs:string and xs:QName.

This is of course a general requirement for user applications, it is not
specific to these functions. It arises for two reasons: (a) users want to
define a function to accept arguments of more than one type (as here), or (b)
users have types defined in their schema as union types, and want to manipulate
values of these types using function calls. For example, I have seen schemas
that contain a type defined as a union of xs:date and xs:gYearMonth, and it
would be convenient to write functions that accept instances of that union
type.

The general idea is that it should be possible in a function signature to
declare the required type of an argument as being a union type, and the
supplied value then matches this type if it is an instance of one of the member
types of the union.

To avoid complications, it is proposed to restrict this to "basic unions",
defined as a simple type of variety union whose base type is xs:anySimpleType
and whose member types are all either atomic or (in XSD 1.1 only) basic union
types. That is, it excludes unions derived by restriction from other unions
(for which the substitutability rules are complex, and buggy in XSD 1.0).

I would propose that we only allow use a named union type defined in the
schema. It would be possible to define SequenceType syntax to define an inline
union type, but this is probably overkill. XSLT already allows the definition
of types locally to a stylesheet by means of an inline schema document.

Sequence type matching works if the supplied value after atomization is an
instance of one of the member types of the union (transitive membership in the
case of XSD 1.1). If an untypedAtomic value is supplied, then it is converted
to the union type by a process analogous to schema validation (try each of the
member types in turn.) 

Static typing works in the obvious way, and is not really different from the
current rules for types element(*, U) and attribute(*, U) where U is a union
type, which we already allow.


-- 
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 Friday, 9 October 2009 15:17:44 UTC