----- Original Message ----- 
From: "Andrew Watt" <andrew@xxxxxxxxxxxxxx>

> 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