W3C home > Mailing lists > Public > www-xpath-comments@w3.org > January to March 2002

Casting from nodes and derived types

From: Jeni Tennison <jeni@jenitennison.com>
Date: Tue, 15 Jan 2002 15:52:05 +0000
Message-ID: <118717267986.20020115155205@jenitennison.com>
To: www-xpath-comments@w3.org

In Section 2.11.2 (Expressions on Datatypes) of the XPath 2.0 WD it

 "Occasionally it is necessary to explicitly convert a value from one
  datatype to another. For the primitive and derived types of XML
  Schema, a cast expression is provided that can convert values
  between certain combinations of types. For example, the expression
  cast as xs:integer (x div y) converts the result of x div y into the
  xs:integer type. The set of type conversions that are supported by
  the cast operator are specified in [XQuery 1.0 and XPath 2.0
  Functions and Operators]. Conversions among user-defined datatypes
  are not supported by the cast notation, but user-defined functions
  can be written for this purpose."

I have two questions/comments about this.

First, what happens if you try to cast a node to a simple typed value?
For example:

  cast as xs:date(appointment/@date)

I think it would make sense for the simple typed value of the node to
be extracted, and that treated as the value to be cast. This would put
it more in line with the implicit casts that you can do through the
basic type conversion rules.

Second, the last sentence is out of sync with the F&O WD, which says
in Section 14.2 that casting from a derived type to a base type is
always permitted (even, presumably, if they are both user-defined
types). I guess that casting down the type hierarchy is not permitted
because it would involve knowing about facets. Even so, it seems a
little strange that you can do:

  cast as xs:double(cast as xs:decimal($integer))

quite happily, but not:

  cast as xs:double($integer)

But this is possibly an issue about the F&O WD rather than the XPath

(Incidentally, given that an XPath processor will have to know about
whitespace to deal properly with converting from strings to simple
typed values, have to know about length to do string-length(), have to
know about patterns to support regular expressions, and have to know
about numeric and date/time comparisons to do gt and lt, it doesn't
seem that much more of a burden to support the totalDigits,
fractionDigits and enumeration facets. I suppose the issue is having
to keep track of all that information about the derived types, but it
seems miniscule compared to the amount that will have to be kept track
of for complex types?)


Jeni Tennison
Received on Tuesday, 15 January 2002 10:52:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:09:42 UTC