Yes, I saw this in the spec, too.
I have two questions:
1. What was the reason for the decision that the typed value of a
text node must be of type xdt:untypedAtomic ? If the node is a *text*
node, then its value must be *text* -- that is *string*.
WGs don't document their reasons for a decision unless challenged. It might
be that different people have different reasons. Sometimes no-one likes it
the way it is, but no-one can suggest an alternative that everyone
prefers...
You seem to be arguing that the typed value should be a string based on some
kind of notion that the English words "text" and "string" are related -
which isn't a good enough reason.
One rationale is that the typed value of the text node should be the same as
the typed value of its containing element.
Another rationale is that nothing in a document should be strongly typed
unless there is a schema to say what the type is.
2. I didn't find in the F & O spec any explanation why a value
comparison (such as lt) of two xdt:untypedAtomic values treats them as
strings. Why not as integers? Why/how this happens? Is there something
like a "preferred/default datatype" for the value-comparison
operators?
The rule isn't in F+O, it's in the XPath language book, at
http://www.w3.org/TR/xpath20/#id-value-comparisons
(see rule 4)
The rationale here, I think, is that lt and le should behave the same as eq,
and string comparison is the most usual eq comparison and therefore the
default.
Michael Kay
http://www.saxonica.com/
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--