Re: XPath and a continuous, uniform information space

Of course we can do that crudely already, using entities or XInclude. Perhaps we just need a smarter implementation of transclusion, where the document fragments are fetched on demand when XPath navigation needs them, rather than being assembled eagerly by the XML parser.

"

it seems to me that this is *exactly* the idea pursued by the approach "super-documents / seamless navigation" sketched in an earlier posting. Or am I mistaken? I would like to know. Differences? Directions in which to seek improvement?

So please forgive me for presenting a literal copy of a part of an earlier posting (see below).

Regards,
Hans-Juergen


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