[Bug 7933] Enhancement to doc() to process a set of URIs

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





--- Comment #1 from Michael Kay <mike@saxonica.com>  2009-10-16 09:08:14 ---
Personal response: Generally we made a design decision that functions in the
standard function library should not do implicit mapping of sequence-valued
arguments. If doc() were to do this, then for consistency we should review the
whole function library to see what other functions should do it: for example,
root(), base-uri(), etc etc.

It seems to me that it is easy enough to write

//@href/doc(.)

to get all the documents linked from the current document, or to write

for $x in $uris return doc($x)

to process a sequence of strings.

(Personally, I would still like to see a simple mapping operator for atomic
values, so that one could write $uris%doc(..) where % is the relevant operator
- the difficulty has always been in finding a suitable operator. I would also
like to see more functions able to default the first argument to ".", including
the ability for user-defined functions to do the same.)

Concerning doc(), it is worth noting that XSLT users have access to the
document() function, which does do implicit mapping. That was one of the
features that the XQuery WG didn't like, which led to the introduction of
doc(). (Other features were the complex rules for determining a base URI). We
certainly wouldn't want to complicate life for XSLT users by giving them a
choice of three functions with different mixtures of implicit semantics.

Finally, a comment on the proposal. It makes no attempt to say why the new
functionality is needed, justifying it solely on the basis that two products
have chosen to implement (conformant or non-conformant) extensions that do
this. That in itself is not sufficient justification.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 16 October 2009 09:08:18 UTC