The definition of fn:doc in the F&O spec

Here is a note from our constituency...

The April 4th version of the fn:doc() function is much too specific and
restrictive.  Why should implementations have to:
 
			1.      Check the lexical space of the fn:doc
argument
			2.      Check to see if the URI contains a
fragment identifier
			3.      Obey rules regarding the media-type
			4.      Honor the URI scheme
			5.      Parse any resource at all
 
The contents of fn:doc should be opaque.  There is no reason why a W3C
spec should dictate implementations to this extent.  For example, some
implementations allow total user control over how the fn:doc() string is
treated.  For example:
 
fn:doc("http://example.com/foo.xml")
 
The user may have total control over how this string is interpreted.  It
can be interpreted as URI with scheme HTTP, in which case the "foo.xml"
file is retrieved from the Internet.  The "foo.xml" file can be parsed
as XML, or turned into a document with one text node that contains all
the markup, or run through an XSLT transformation before being returned
to the XQuery processor.  "foo.xml" can even be interpreted as an opaque
identifier (not a URI) which causes a dictionary lookup of a cached data
source.  It can be interpreted in *any way the user likes*.  It is very
important to implementations that this be allowed.  Many will not do any
validation or parsing of the string that is passed to fn:doc.  The user
has total control and will do whatever parsing/interpretation that is
necessary.
 
Given this, here are the only restrictions that fn:doc should have:
 
			1.      The fn:doc function must return either a
single document node, or else the empty sequence.  This restriction
exists in order to allow static typing to have a well-known "entry
point" into the document.
			2.      The fn:doc function is stable.  This
restriction exists for usability and freedom from potentially nasty side
effects.  Users want each unique fn:doc identifier to map to exactly one
data source.
 
That's it.  The entire fn:doc text should be collapsed to something like
this:
 
 
                                                          
fn:doc($id as xs:string?) as document?
Retrieves a document identified by xs:string argument.  This function
must return a document node with untyped or typed content or the empty
sequence.
If $srcval is the empty sequence, the result is an empty sequence.
This function is *stable* <file:///C:\temp\xq-fo.html> . Two calls on
this function return the same document node if the same identifier is
supplied to both calls. Thus, the following expression (if it does not
raise an error) will always be true:
doc("http://example.com/foo.xml") is doc("http://example.com/foo.xml")
Note:
The details of binding the identifier to a particular resource are
implementation-defined:
		 
doc("foo.xml")
 
One implementation might treat this as a relative URI and resolve it to
an absolute URI using the Base URI in the static context.  Another
implementation might treat this as a key into a hashtable of cached data
sources.  Yet another implementation might treat this as a relative file
URI into the current directory.  Furthermore, implementations are free
to provide any number of options and/or user hooks to customize the
behavior of XML resource binding.
 

All the best, Ashok