----- Original Message -----
From: "Andrew Watt" <andrew(_at_)andrewwatt(_dot_)com>
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.
I am less concerned about attaining such basic knowledge than I am that my
stylesheets will need it.
<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.
It would not in XSLT 1.0. This is my concern. Do I need to start catching
lexical errors in my stylesheets?
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.
And this is where I get hung up. XSLT v1.0 this is just crap data that needs
proofreading. In XSLT v2.0, even for a Basic XSLT Processor, this is a run-time
failure that I can't recover from. Somebody else must see this a problem or I
am missing something big somewhere in the literature.
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.
In the absence of PSVI annotation, what is it? A great comfort of XSL 1.0 is
that everything is either a string or it is a nodeset that has a straightforward
string value: text(). Can I starts-with() an xdt:untypedAtomic or must it be
cast as a string?
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.
I think that this is mistaken. Simple, happily munged strings of characters do
not generate run-time failure in XSLT 1.0. Everything I've read so far
indicates to me that even a Basic XSLT Processor written to the current draft
must fail on lexical errors.
Again, I am less concerned about *doing it the old way* or *avoiding complexity*
than I am about exposing new run-time errors. Is this a job for fallback
processing?
Mike
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list