At 04:06 13/05/2003 -0500, you wrote:
That assumption of castability creates the potential for a class of errors
that
stylesheets were previously not susceptible to, correct?
Yes, I think so. It's partly why I said in an earlier post (I can't
remember which list) that, for example, someone wanting to make use of the
new date / time function must attain *some basic* knowledge of at least the
lexical form of date types.
To complicate your *silly* example:
Hey, come on it wasn't *that* silly. <grin/>
<MyDate>Fred</MyDate>
<MyDate>2003-5-15</MyDate>
Its not clear to me how automatic casting operates over these elements.
The first would generate an error, in my expectation.
The second probably would generate an error too, I think. Why? Because
xsd:date is expecting CCYY-MM-DD and your example supplies only CCYY-M-DD.
I just tried it in Saxon 7.5 and it complained it couldn't convert
"integer" (not sure where it got that from) to "date". But it gives the
same error message for 2003-05-15, so maybe xdt:untypedAtomic isn't fully
implemented in Saxon 7.5 yet.
But
<MyDate>2003-05-15</MyDate>
should, in my expectation, be processed transparently if everything works
as it is claimed to work.
> 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.
I guess it depends on what you mean by "limits". I don't know a way to cast
"Fred" to a meaningful date. I suspect you don't either. So there *are*
limits but not specifically of the xdt types.
Is
xdt:untypedAtomic ever anything more or less than a collection of unicode
points?
I think the WG will tell you that they are different and that
xdt:untypedAtomic is a collection / sequence of code points which has been
annotated as xdt:untypedAtomic.
Whether you accept that that is genuinely something different is a separate
question, in my view.
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?
Judging by initial experience of Saxon 7.5 it says it can't do it and the
transformation won't be carried out.
But Saxon 7.5 documentation is explicit that many aspects of typing are not
yet implemented.
*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.
Good. It will be useful to trade experiences.
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?
I *think* that what worked transparently before will work transparently in
XSLT 2.0. At least that is what I understand the WG to be saying.
So, if for example, you want to manipulate dates as strings ... or do I
mean strings as dates? :) ..... and play around with substrings to format a
date then you will still be able to do as you did in XSLT 1.0 (without
having to think about W3C XML Schema datatypes), but if you want to be able
to use the new XPath 2.0 date / time / duration functions you will need at
least a basic understanding of how these "types" are expected to look when
they are untyped strings.
And in light of the new range of failure this exposes, do we get *trys* with
this shake?
Not as far as I am aware.
Andrew Watt
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list