Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0

Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0
From: "Mike Haarman" <mhaarman@xxxxxxxxxxxxxxxxxx>
Date: Tue, 13 May 2003 04:06:00 -0500
----- Original Message ----- 
From: "Andrew Watt" <andrew@xxxxxxxxxxxxxx>

> You might want to take a look at the questions I posed on
> public-qt-comments a day or two after the new Working Drafts came out and
> the follow-up answers from David Carlisle and Michael Kay:

I have and I'll quote from them in a moment.

> Values of the "untyped type" can be cast automatically to the desired type.
> Then things work as if it had been typed in the first place, assuming that
> the string which is of "untyped type" is castable to the type that the
> function expects.

That assumption of castability creates the potential for a class of errors that
stylesheets were previously not susceptible to, correct?

To complicate your *silly* example:


Its not clear to me how automatic casting operates over these elements.

> A (heretical?) thought that is beginning to float around in my mind ...
> Dave Pawson may approve of this :) .... is why can't we just treat untyped
> strings (which the WD proposes are treated as xdt:untypedAtomic) as ...
> well .... xsd:string types?

That can't be so heretical if there are limits on xdt:untypedAtomic.  Is
xdt:untypedAtomic ever anything more or less than a collection of unicode

Mike Kay replied in the thread linked above:

*No, all the functions are available. The only facilities that won't be
available are those explicitly associated with schemas and complex types.*

How is *won't be available* expressed by the processor when a function is
presented with an argument it cannot coerce?

*It is described in the "Conformance" section of the XSLT specification.
Obviously, we hope that we've got it right and that it is practical and
useful. It actually corresponds fairly closely to the subset of the spec
implemented in Saxon 7.5, so there is some opportunity for users to give us
practical feedback on whether it works.*

I'll make time to begin experimenting with this.

David Carlisle replied in the same thread:

*So I think this means that If you use a date function on a string
extracted from an untyped input doc, it will be coerced to a date type
before calling the function.*

Here is my narrative:

I set out to write a stylesheet in XSL2 without reference to a schema.  I hope
to operate merely over the tree as exposed by axes and attributes, expecting
only a well-formed instance.

Is it merely irresponsible practice to make use of xdt: reliant functions of
XPath in light of such requirements or am I limited to Andrew's *loosely typed
profile* by the processor?  Is this implementation specific behavior?

And in light of the new range of failure this exposes, do we get *trys* with
this shake?


 XSL-List info and archive:

Current Thread