Re: No-fail `document` Function Spec

On Tue, Mar 07, 2006 at 02:50:14PM -0700, Mike Brown wrote:
> Anyway, following some discussion on IRC, John asked me to post some of my
> feedback to the list.

Thanks for commenting, Mike.

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

Actually, such a system property would almost satisfy me.  I don't like
the idea of a toggle (on its own, without a system property) because I
want the XSLT itself to know whether the call might abort-on-fail.

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

Right, but how is this any different from the original `document`
function?  I don't think it gives any guarantees that the `document`
function will always return the same node-set for the same URL, does it?
I know that it asserts that

  generate-id(document("foo.xml"))=generate-id(document("foo.xml"))

will always be true, but does that mean that the node-sets have to be
the same?  Isn't this basically the general point where I/O gets in the
way of functional principles?  There are a number of ways that we could
add in some pure functional characteristics, but they seemed to get in
the way of, er, functionality.

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

I agree; I was trying not to make too many assumptions, but perhaps I
was less than successful.  On the other hand, I was thinking (but didn't
encode it anywhere) that processors could add their own elements into
the error document mix as they saw fit.  Primarily, I was trying to hit
the sweet spot of being able to track HTTP errors when they occur, while
still allowing reporting other sorts of errors.

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

I like this idea as well, but I think that the primary need for such
error reporting exists in retrieving external documents.  Also, it's
harder to come up with something more general.  I'd be interested in
seeing other places where you think this general error-reporting could
be useful.

Take care,

    John L. Clark

_______________________________________________
exslt mailing list
[email protected]
http://www.exslt.org/list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFEDhwrjkcskvOyl78RAv6kAJ96SeVbx7sJ8Fx71C2KLnAWbNqAGwCgkRgo
uq4ZZHxOwiy4fU0LeUXSWBw=
=2Pjz
-----END PGP SIGNATURE-----