7860 2009-10-09 15:17:42 +0000 [XPath 2.1] Union type as declared function argument 2013-06-19 07:52:09 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XPath 3.0 Recommendation PC Windows NT CLOSED FIXED P2 normal --- 1 mike jonathan.robie jim.melton zongaro public-qt-comments oldest_to_newest 28169 0 mike 2009-10-09 15:17:42 +0000 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. 29610 1 mike 2009-11-17 13:59:16 +0000 A proposal to address this problem (along with bug 7749) is at http://lists.w3.org/Archives/Member/w3c-xsl-query/2009Oct/0133.html (member-only) 32300 2 jonathan.robie 2010-02-17 22:30:44 +0000 (In reply to comment #1) > A proposal to address this problem (along with bug 7749) is at > > http://lists.w3.org/Archives/Member/w3c-xsl-query/2009Oct/0133.html > > (member-only) > The WG has adopted this proposal (http://lists.w3.org/Archives/Member/w3c-xsl-query/2010Jan/0081.html): I think the changes to our specification needed to plug this usability gap are very modest. Define the construct AType to be an atomic type or a union type that does not impose any restrictions beyond those imposed by its member types (for a way of saying this more formally, see Type Derivation OK (Simple) in XSD 1.1). Then we allow an AType to be used as an ItemType in the SequenceType production (in place of the current AtomicType), and in 2.5.4.2 we say that when the AType is a union type, then it matches an atomic value if and only if one of its member types matches that atomic value. I will add this to the internal working draft. 42395 3 jonathan.robie 2010-11-10 21:43:22 +0000 I'm tempted to use the existing AtomicType production, modifying the semantics to match the proposed semantics for AType. That's editorial - it doesn't affect the language - but I'm stating this here so anyone who wants to provide feedback has a head's up. 42433 4 zongaro 2010-11-11 14:11:15 +0000 (In reply to comment #3) > I'm tempted to use the existing AtomicType production, modifying the semantics > to match the proposed semantics for AType. So, you're musing about something like this. Leaving this production as it is: [172] AtomicType ::= EQName and changing the following sentence in section 2.5.4.2 to replace "defined as an atomic type" to " defined as an atomic type or a union type"? "An ItemType consisting simply of an EQName is interpreted as an AtomicType. An AtomicType AtomicType matches an atomic value whose actual type is AT if derives-from( AT, AtomicType ) is true. If the expanded QName of an AtomicType is not defined as an atomic type in the in-scope schema types, a static error is raised [err:XPST0051]." If I've understood you correctly, I think that as a reader I would find it quite confusing to have to read "AtomicType" as meaning "atomic type or union type," but "atomic type" as meaning "atomic type." 42438 5 jonathan.robie 2010-11-11 16:02:37 +0000 (In reply to comment #4) > If I've understood you correctly, I think that as a reader I would find it > quite confusing to have to read "AtomicType" as meaning "atomic type or union > type," but "atomic type" as meaning "atomic type." True. Perhaps AtomicOrUnionType would be better ... a bit long. 42455 6 jonathan.robie 2010-11-11 21:47:19 +0000 The proposal says this: > We could also extend casting to allow casting to a union type, > but I don't think that's essential. The minutes do not state whether we decided to allow this. 42552 7 jonathan.robie 2010-11-15 23:04:11 +0000 *** Bug 10568 has been marked as a duplicate of this bug. *** 42910 8 jonathan.robie 2010-11-30 16:57:39 +0000 The Working Group decided that we will support casts and constructor functions.