To whit, using xs:dateTime. In order to utilize functions on
this datatype in both validating and non-validating
environments without the danger of an unrecoverable run-time
error, I must:
10 test whether datapoint is appropriately type annotated
20 if yes, go to 60
30 if no, test whether data is castable as xs:dateTime
40 if yes, cast and go to 60
50 if no, resort to string pfaffing or throw error
60 fn()
Not so. If you have an attribute @dob whose string value is a date, but
you aren't sure whether it is annotated as a date or not, then you can
simply do:
format-date(xs:date(@dob), "[D] [Mn] [Y]")
If you want something other than a failure in the case where @dob is an
invalid date, you can do:
if (@dob castable as xs:date)
then format-date(xs:date(@dob), "[D] [Mn] [Y]")
else "** invalid date of birth **"
For all the safety the proposed typing regime provides
against delivering or receiving nonsense, it has a negative
impact on coding efficiency if that code must work within
both validating and non-validating environments alike.
Let me say I would like very much to be wrong about this.
I think you are wrong, for two reasons. Firstly, in most cases code
written to handle unvalidated documents will still work when the
documents are validated (the main case that needs care is list-valued
attributes). Secondly, I don't think this scenario, where you don't know
in advance whether the documents are validated, is very plausible. We
have yet to see how products handle this, but I suspect most products
won't validate a document unless you specifically ask them to.
Michael Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list