Re: No-fail `document` Function Spec

Sylvain Hellegouarch wrote:
> In fact although technically Aristotle was right, the American English 
> abuses the grammar and uses "license" as a word. That's actually a way 
> to differentiate an American from a British. :)

Actually the difference is usually evident by the chip on the Brit's shoulder
over the expectation that spelling and grammar is theirs to dictate to all
their former colonies and to everyone else in the world, rather than being a
vibrant, evolving, many-faceted family of languages subject to the influence
and cross-pollenation of many different cultures. For 230 years we Yanks have
felt absolutely no pressure to conform to legacies of colonialism that many
people, even in these enlightened times, continue mistake for global consensus
on so-called standard English. However, spurious claims of ownership of a
language and cheap airfare within the Commonwealth seem to be all that's left
of the Empire, so I suppose if it makes the Brits feel better, we can set up a
filter on the list that replaces American spellings with their archaic
alternatives so that sensitive eyes won't be offended.

(I see we haven't shed the British penchant for sarcasm, though, have we?)

Anyway, following some discussion on IRC, John asked me to post some of my
feedback to the list.

While ('scuse me, "WHILST") I'm not opposed to the no-fail document()
function, my first reaction was "shouldn't that just be a switch on the
processor?" I mean, I doubt someone is going to want both fail and no-fail
document() behavior (oops, BEHAVIOUR), so processors could just offer it as a
toggle. Even if they don't, we could still define a system property that we
could query to find out if a failed document() call might abort processing,
and stylesheet authors could code around it accordingly.

My second reaction is more of a general discomfort to having a function
resolve unpredictably, much like math:random(), given the same set of
arguments --functional principles and all that.

My third reaction was that the "protocol error" seems like something that we
don't want to make too many assumptions about. A URI that can't be resolved is
one class of failure cases, and a URI that can be resolved to a resource
representation that can't be converted to a node-set is another. To offer any
more detail (HTTP 404, OS file not found, catalog errors, etc.) has to be
implementation-dependent, IMHO, because we don't really know anything about
the resolver in use.

This got me to thinking that perhaps a more general error-trapping and        
exception-querying mechanism might be more desirable. When I make use of *any*
XSLT instruction or XPath expression (not just document()) that has the       
potential to result in a runtime error that is considered, at the processor's 
discretion, to be fatal or non-fatal, I might want to see what the error was  
and react to it. In other words, a general-purpose set of try-except and 
processor state query extensions seems more useful than redefining specific
functions to get the same info.

As I said, though, I don't stand opposed to the no-fail document() proposal.
I am just here to overthink it and make it more complicated :)

Mike