Re: [xml-dev] XPath and a continuous, uniform information space

Michael, Uche,

referring to Michael's words:

Come to think of it, perhaps the problem is more that we equate an "XML document" to a "web resource". What we perhaps need is a way of distributing a single XML document over a large collection of web resources, and then navigating around that XML document seamlessly, using XPath?

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.