[Bug 9606] Run-time QNames in xsl:key etc.

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

--- Comment #3 from Michael Kay <mike@saxonica.com> 2010-10-14 16:15:23 UTC ---
Copy of email written today:

The consensus we reached last week was to define functions like key() to accept
a union type as the argument.

For example

key($keyname as u:qname-union-type, $keyvalue as xs:anyAtomicType)

where u:qname-union-type is defined as a union of LexicalQName and xs:QName,
perhaps:

<xs:simpleType name="qname-union-type">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:Name"/>
<xs:pattern value="([^:]+:)[^:]+">
<xs:annotation>
<xs:documentation>
<p>An XML Name containing at most one colon, which must not be first or
last</p>
</
</
</
</
</xs:simpleType>
<xs:simpleType ref="xs:QName"/>
</xs:union>
</xs:simpleType>

The type u:qname-union-type can then be used in all the following:

element-available(U)
function-available(U, arity)
type-available(U)
system-property(U)
format-number(N, P, U)
key(U, V, R)

Note that these are all XSLT-only functions except format-number(), which has
drifted into XPath.

The proposal doesn't help with QName-valued attributes of xsl:result-document
(e.g format), as these are provided as AVTs which must therefore be strings.

The trickiest part of introducing this is that it requires a new schema and a
new namespace. Users wouldn't actually need to refer to this new union type by
name, but we probably have to "do things properly" and define the type in a
schema somewhere and give it a proper name.

The other thing that could be tricky is that using a union type here invites
the possibility of doing the same thing elsewhere, for example using a union
type for date/time/dateTime arguments of functions like format-date. It would
certainly have been nice had the facility been available at the time, but it's
difficult to change the style retrospectively.

-- 
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 Thursday, 14 October 2010 16:15:25 UTC