W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

Re: [xsl] Using or ignoring Types in XSLT 2.0 / XPath 2.0

From: Mike Haarman <mhaarman@infinitecampus.org>
Date: Fri, 16 May 2003 04:58:17 -0500
Message-ID: <000201c31bbe$294b1af0$c70aa8c0@ic.org>
To: <xsl-list@lists.mulberrytech.com>, "'Michael Rys'" <mrys@microsoft.com>, <public-qt-comments@w3.org>

----- Original Message ----- 
From: "Michael Kay" <mhk@mhk.me.uk>

Michael,

Thanks for your instructive reply and your patience in getting to the question.

> 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 **"
>

Or more at what I am thinking:

   if (@dob castable as xs:date)
     then format-date(xs:date(@dob), "[D] [Mn] [Y]")
     elseif (i can decide what wrong)
       then "description" | $index.to.error
       else $junk

There are times when you want the junk coming in to spill out the other end of
the pipe.  Then you can go back and fix the source of the junk.  You want to
expose the source and nature of the problem.

> 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).

Or more precisely, as I've learned, type-annotated documents, since it seems
clear that annotation without validation is something an API may well want to
provide.  I'll have a look at 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.

Though I think the case where you don't want to care is quite probable.
Building along a filter pattern as above, for testing I want to be able to
validate an instance my source generates, but I don't want to ensure *each*
instance the source emits is valid.  If I start getting nonsense I want to dump
it to output so that I can have a look and fix whatever my source is getting.
As well, a different source for the pipeline may be validating its data on its
own for whatever reason.

It appears that I can have my typing cake and eat my junk data, too.  It's
natural behavior under 1.0, just something that needs built if you want it under
2.0


Much obliged,

Mike
Received on Friday, 16 May 2003 11:17:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:24 GMT