I've always thought it a weakness of the XML model that resource boundaries were visible at all. In your example, the calls on doc() to cross resource boundaries are explicit.
When you're designing an XML database, deciding what information to put in one document can be a major headache (e.g. if you're managing hotel bookings, how should hotel bookings be grouped into documents?) I've always felt it
shouldn't matter: there should be a single data hierarchy in which the resource boundaries are totally invisible.
"
To this some responses.
Forest inescapable
=============
Doubtless it would be unrealistic to think of a single hierarchy organizing the global information space (sum total of all accessible XML resources). As such a single hierarchy is out of the question, the information space is inescapably a node forest. The question is whether the trees of the forest must necessarily be documents or if there may be also "super-trees", spanning sets of documents. And I am convinced that this is possible, it only requires additional data ("navigation support data") hosted by additional resources which specify the integration of (primary) resources into hierarchical structures. (In analogy to linkbases which are additional resources specifying resource relationships.) One such approach is tree-structured URI catalogs.
Hiding
resource boundaries vs. creating huge resources
======================================
(Aside: inserting data into a database without discerning documents amounts to creating very big documents, doesn't it? In principle, this does not obliterate resource boundaries, it only creates huge resources.)
Super-documents as a view
===================
What I find very interesting is the possibility to *impose* a super structure on a given set of documents, integrating them into a single logical tree. The super-document is essentially a *view* imposed on a set of documents. Having accomplished this, one may alternatively deal with the documents in the conventional way (as independent entities), or in a novel integrated way, navigating the super-document. In the latter case, overall navigation can be viewed as the merging of two kinds of movement, moving within the super-structure from "part" to "part" (where parts are documents, physically),
and down into the "parts". And this is exactly the behaviour mimicked by the example, which navigates the tree-structured catalog and then drills into the documents.
Seamless navigation of super-documents
============================
So your remark that "the calls on doc() to cross resource boundaries are explicit" points to the fact that one can imagine better built-in support by XPath, support which makes such navigation still more elegant: instead of using fn:doc (synonymous with - "I enter a resource") just going "into" the node containing the URI. For example, one might think of a new data type (possibly coupled to a reserved QName like xml:resolvable) representing resolvable URIs (say, xs:resolvableURI), so that the resolving of the URI is automatically (!) performed when the context node has as type xs:resolvableURI and a downward navigation takes place. So...
instead of:
//uri/doc(.)//country
we might have: //xml:resolvable//country
where our catalog has been changed to this:
<doctree>
<department name="culinary">
<project name="people-and-foods">
<xml:resolvable application="persons">persons.xml</uri>
<xml:resolvable applications="foods">foods.xml</uri>
</project>
<project name="equipment">
<xml:resolvable application="blenders">blenders.xml</uri>
<xml:resolvable application="coffee-makers">coffee-makers.xml</uri>
</project>
</department>
...
</doctree>and where XPath has learned to treat context nodes of type xs:resolvableURI specifically. (This might requrire the introduction of a new node property - [virtual-children] - which are the nodes obtained by resolving the URI which is the typed value of the node.) There are interesting perspectives which might deserve careful analysis.
Web architecture of XML technology?
==========================
Finally, you wrote: "I'm sure that's achievable, but the web architecture doesn't encourage it." To me it is a question if it is really web architecture what is responsible for the status quo, or not simply the limited features of XML/XPath itself - is it not XML/XPath what is responsible how links are expressed and resolved?
