RE: [XSLT20] errors raised by document()

Thanks for the comment.

We (XSL-WG) haven't yet got around to discussing the implications of
doc-available() on the spec of document(), though we are planning another
general review of all recoverable errors. So this comment is timely.

There are three possibilities, I think:

(1) document() always returns () if document is not available. This is your
proposal, I think.

(2) document() always fails if document is not available. The user can guard
it by calling doc-available().

(3) status-quo: it's implementation-defined

My own instinct is towards (2). Since it's implementation-defined in 1.0,
either (1) or (2) is going to force some implementations to be
backwards-incompatible, and we'll need to take this into account.

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: public-qt-comments-request@w3.org 
> [mailto:public-qt-comments-request@w3.org] On Behalf Of David Carlisle
> Sent: 14 February 2005 12:59
> To: public-qt-comments@w3.org
> Subject: [XSLT20] errors raised by document()
> 
> 
> 
> summary:
>   A suggestion to change document() to call
> 
>   if (doc-available(...)) then doc() else ()
> 
>   rather than doc()
> 
> rationale:
> 
> document() inherits from XSLT1 the feature that it is a recoverable
> error if the document can't be returned, with the recovery being to
> return an empty node set.
> 
> This means that in most but not all XSLT1 implementations you can test
> for a document with
> <xsl:if test="document('abc.xml')"> ....
> 
> presumably the reason why this behaviour was made optional was that it
> was thought that some errors in handling external documents 
> might be out
> of the control of the XSLT processor. 
> 
> However the February 2005 draft of F&O does assume that the processor
> can safely detect this, and introduces the doc-available()
> function.
> 
> An alternative would have been to mandate that doc() returned () if no
> document node was available, but given the desire to keep 
> doc() "simple"
> the new function is a reasonable approach.
> 
> However for document() the situation is rather different as 
> it's already
> doing quite a lot, and changing it to test with doc-available()
> doesn't really harm compatibilty (since that behaviour was allowed in
> XSLT1) and it would help improve interoperability  between 
> XSLT2 systems
> as system-defined recoverable errors are a major potential source of
> difference between systems.
> 
> I note in passing while the addition of doc-available() means 
> that calls
> to doc() and document() can be guarded against recoverable 
> errors due to
> missing files, the xslt-only function unparsed-text() has no 
> such guard
> as doc-available checks that the URI resolves to a document node, not
> just that it can be resolved to something. If document() was 
> changed as
> suggested to automatically do this check, probably 
> unparsed-text() ought
> to change to match. If it isn't changed, perhaps a similar 
> guard function
> for unparsed-text() should be added.
> 
> 
> David
> 
> ______________________________________________________________
> __________
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ______________________________________________________________
> __________
> 
>

Received on Monday, 14 February 2005 13:41:08 UTC