Re: No-fail `document` Function Spec

John L. Clark wrote:
> Mike Brown wrote:
> > 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?

I sure hope so! If the ID of node x and the ID of node y are the same, then
node x *is* node y. There is no way for x to be part of a different document 
than y.

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

Actually I think it depends on how we look at it. "document('foo.xml')" is
deceptive. There's a hidden argument: either the context, or the base URI,
which you get from the context.  Practically speaking, it includes other
hidden arguments such as the resolver's capabilities and state, which in turn
may be affected by network state at evaluation time, so the actual time (in
the universe, not on the system) can be considered a hidden argument, as well. 

The generate-id() equality requirement prevents us from getting too carried
away with that, though...at least for a given evaluation of a stylesheet. As
it stands, you *do* have a guarantee that 'document' represents / will return
the same node-set for the same URL, throughout the stylesheet (for a given 
run).