XSLT 2.0 and XPath 2.0 Programmer's Reference, 4th Edition (632 page)

See Also

false()
on page 779

type-available

This function is available in XSLT only
.

This function is used to test whether a particular schema type is available in the static context.

For example, the expression
type-available(‘xs:integer’)
returns
true
.

Signature

Effect

The first argument must take the form of a lexical
QName
; that is, an XML name with an optional namespace prefix that corresponds to a namespace declaration that is in scope at the point in the stylesheet where the
type-available()
function is called. If the name is unprefixed, then the default namespace from the stylesheet (defined by
xmlns=“some.uri”
) is assumed.

With a basic XSLT processor (the minimal conformance level), the function returns true if the name is one of the following:

• One of the schema primitive types available in every XSLT processor:
  xs:string
  ,
  xs:boolean
  ,
  xs:decimal
  ,
  xs:double
  ,
  xs:float
  ,
  xs:date
  ,
  xs:time
  ,
  xs:dateTime
  ,
  xs:duration
  ,
  xs:QName
  ,
  xs:anyURI
  ,
  xs:gDay
  ,
  xs:gMonthDay
  ,
  xs:gMonth
  ,
  xs:gYearMonth
  ,
  xs:gYear
  ,
  xs:base64Binary
  , or
  xs:hexBinary
  
• One of the derived built-in types available in every XSLT processor:
  xs:integer
  ,
  xs:yearMonthDuration
  ,
  xs:dayTimeDuration
  
• One of the special types
  xs:anyType, xs:anySimpleType, xs:anyAtomicType, xs:untyped, xs:untypedAtomic
  

With a schema-aware XSLT processor the function will also return true if the type is one of:

• The abstract primitive type
  xs:NOTATION
  
• One of the derived built-in numeric types
  xs:nonPositiveInteger
  ,
  xs:negativeInteger
  ,
  xs:long
  ,
  xs:int
  ,
  xs:short
  ,
  xs:byte
  ,
  xs:nonNegativeInteger
  ,
  xs:unsignedLong
  ,
  xs:unsignedInt
  ,
  xs:unsignedShort
  ,
  xs:unsignedByte
  ,
  xs:positiveInteger
  
• One of the derived built-in string types
  xs:normalizedString
  ,
  xs:token
  ,
  xs:language
  ,
  xs:NMTOKEN
  ,
  xs:Name
  ,
  xs:NCName
  ,
  xs:ID
  ,
  xs:IDREF
  ,
  xs:ENTITY
  
• One of the built-in list types
  xs:ENTITIES
  ,
  xs:IDREFS
  ,
  xs:NMTOKENS
  

Vendors are allowed to define additional types in their own namespace, and
type-available()
can also be used to test for these types.

Usage

The stated purpose of this function is to allow you to test whether a particular type is available for use, so that you can conditionally exclude code that refers to a type if it is not available. However, its practical usefuless is limited by the fact that types imported using

are not available in the static context for an
[xsl:]use-when
expression, which means that testing for the availability of a user-defined type in
[xsl:]use-when
will always return false.

In practice, therefore, this function is only likely to be useful when testing for vendor-defined types which might be imported implicitly.

See Also

element-available()
on page 764

function-available()
on page 792

system-property()
on page 890

in Chapter 6, page 316

unordered

The formal definition of the
unordered()
function is that it returns a sequence that is an arbitrary reordering of the sequence provided as its argument. In practice, this is really a pseudo-function—wrapping an expression in a call of
unordered()
tells the XPath processor that you don't care what order the results of that expression are in, which means that the processor might be able to avoid the cost of sorting them into the right order.

For example,
unordered(ancestor::*)
returns the ancestor elements in whatever order the system finds most convenient. (In Saxon, it currently returns them in reverse document order, that is, innermost ancestor first.)

Signature

Effect

The ordering of the items in the result is arbitrary, which means the processor can choose any order it likes. This doesn't mean it has to be a randomized order; on the contrary, the system might well choose to return the original order unchanged. In fact, it would be completely conformant with the specification for this function to be implemented as a no-operation. It's really best to think of it as an optimization hint.

Note that although the
unordered()
function allows the system to return the results of the argument expression in any order, it doesn't absolve it from the need to eliminate duplicates. In practice this reduces the possibilities available to an optimizer considerably; for example, in forming a union between two sequences of nodes
$A|$B
, the system is required both to sort the result in document order and to remove duplicates. Writing it as
unordered($A|$B)
removes the requirement to sort the results, but not the requirement to eliminate duplicates. Since the system is very likely to eliminate duplicates as a by-product of sorting, this might not result in any changes to the execution strategy chosen by the optimizer.