[Bug 3173] [F+O, DM] A difficulty with document-uri()

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3173





------- Comment #6 from holstege@mathling.com  2006-06-16 22:14 -------
I like the linkage of stability into the mix, but I still don't understand
why the notion of "documents obtained as a result of calling fn:doc" and
documents obtained by other means is necessary or helpful.  If an
implementation
can handle stability, it can handle stability. If it can't, it can't. I think
adding the linkage to stability is all we need to do, and drop all the
additional caveats and exceptions. Adding in the clarification under "available
documents" is good too.

For example, why fn:collection should be included in the list of
the non-guaranteed? Implementations that have it it will most likely use it
simply as a convenient way of getting at a named set of document nodes
instead of having to concatenate a sequence of fn:doc calls, so ensuring
the guarantee costs nothing more than it does for fn:doc, but by taking away
the guarantee you have also made it so one can't write applications that can
use the generic label in place of specific document URIs. It also means you
are dropping guarantees for any vendor-specific extension functions that fetch
or construct document nodes, which, given the nature of this area of the spec,
I would consider highly likely to exist.  But even when you look at things like
parameters to queries (by which I assume you mean external variables). I really
don't see why, given I have a document node in my hand, it is any kind of 
problem to -- if it has a document-uri at all -- to make sure that fn:doc
returns that guy if you have a stable implementation. That's the work a stable
implementation needs to do.

Received on Friday, 16 June 2006 22:14:34 UTC