Subject: Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0|
From: Andrew Watt <andrew@xxxxxxxxxxxxxx>
Date: Tue, 13 May 2003 11:08:40 +0100
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 points?
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?