6.1 Restrictions on Query Shipping
6.1.1 Local Data of Links
Consider a link which containslocal data, i.e. non-xlink- and non-dbxlink-attributes, text children or subelements. If query shipping should be applied for this link element, intuitively, both the link’s local data and the remote parts have to be respected. Due to this, several problems arise. For instance, both the local and remote data might contribute to the result set of the given user query. Also, if the query is shipped, the local data is not “reachable” anymore and sometimes it is necessary to have the data
“in one place”.
Only links with drop-element as “L”-directive do not have to be considered here.
According to the modeling semantics of this directive, the local link element is dropped completely and thus its local data is not relevant for the query. However, for a link which has any of the other “L”-directives and if it also has local data, we argue that query shipping should not be applied and therefore give some illustrating examples.
Remark. One possibility to overcome this problem would be to ship the query and any local data contained in the link’s subtree. Then, we would have all relevant data in one place, namely on the remote server. On the other hand, the idea of query shipping intends to reduce network traffic and not to ship any data which might not be accepted by remote servers anyway.
group-in-element. Any expression contained in predicatex has to be evaluated locally because if the link contains a body, then its local attributes or subelements might satisfy the predicate. However, there might be cases where italso has to be checked remotely.
An example will clarify this issue.
Thecity elements could be modeled with an additionaltemperature link for integrating the actual temperature into the local data. For instance, consider Berlin:
<city>
<name>Berlin</name>
<population year=”95”>3472009</population>
<temperature time=”now” dbxlink:eval=”remote”
dbxlink:transparent=”group-in-element insert-bodies”
xlink:href=”http://. . . /temp.xml#xpointer(//city[name=’Berlin’]/temp)”/>
...
</city>
With this modeling, in the virtual instance, the city element’s child temperature would be enriched with the actual temperature in degree Celsius obtained from a remote file
“temp.xml”. Assume that this file is structured as follows:
<temp measurements>
<city>
<name>Berlin</name>
<temp>18</temp>
</city>
...
</temp measurements>
Thus, the virtual instance contains the referenced temperature:
<city>
<name>Berlin</name>
<population year=”95”>3472009</population>
<temperature time=”now”>18</temperature>
...
</city>
Now, consider the following example query which selects the name of all cities where the actual temperature is below 20 degrees:
//city[temperature/@time=”now” and temperature/text()<20]/name
As Berlin qualifies wrt. the predicate, we expect its name to be contained in the result set. If evaluated via data or hybrid shipping, where a partial instance is materialized locally, the computation delivers the correct result in a straightforward way because all relevant nodes are found in one place. But in case of query shipping, we have to be aware that in general, the predicate has to be checked both locally and remotely. In the example above, a predicate containing a conjunction of predicates like “[cond1 and cond2]” is given wherecond1 is satisfied locally by thetimeattribute andcond2 qualifies remotely by the referenced actual temperature.
This example shows why it is appropriate to fall back to hybrid shipping if links having local data and equipped with group-in-element as “L”-directive are given. The main reason for this is due to the necessity that relevant data should be accessible in one place, be it remotely or locally. The following paragraph shows similar examples for the other “L”-directives.
duplicate-element, keep-body and make-attribute. Recall the example already used in Section 3.2.1 for illustrating the modeling of duplicate-elementwhere extra cities ref-erenced astown elements in a filegermantowns.xml are included for Germany:
<country>
<name>Germany</name>
...
<city source=”not approved” dbxlink:eval=”remote”
dbxlink:transparent=”duplicate-element insert-bodies”
xlink:href=”http://. . . /germantowns.xml#xpointer(//town)”/>
...
</country>
The city element is duplicated according to the number of referenced elements repre-senting these German towns. Thus, in the virtual instance induced by this fragment, all city elements are enriched with an source attribute which stems from the original link element:
<country>
<name>Germany</name>
...
<city source=”not approved”>
<name>G¨ottingen</name>
<population>129051</population>
</city>
<city source=”not approved”>
<name>Braunschweig</name>
<population>245273</population>
</city>
...
</country>
If the city link would have an attribute dbxlink:transparent=”keep-body insert-nodes”, the induced virtual instance would have a similar structure consisting of town elements becausekeep-bodyforces the link element to be replaced by the referencedtownelements to which thesourceattributes are added. Thus, a similar example can also be constructed forkeep-body.
Now, assume that the following query is stated, querying for allsource attributes:
//country[@car code=’D’]/city/@source
We have not yet discussed how the query to be shipped is built but the idea is to delegate a combination of the XPointer and the rest of the query to the remote server. For the example query given above, the final result set consists ofsourceattributes which amount to the number of referenced towns. Obviously, these attributes would not be selected by a shipped query because remotely, no such attributes reside. In this example, we would have to request the remote server how many element nodes are returned by the
XPointer in order to add the appropriate amount of sourceattributes to the final query result set. This would be equivalent to a hybrid shipping which requests the fragment referenced by the link’s XPointer. Thus, it shows already in this simple example that a query shipping is not feasible. We argue that in this case we should fall back to hybrid shipping in order to build the partial instance locally.
Links having local data and the “L”-directive make-attribute can create a similar sit-uation. Consider an alternative modeling of the cities link for referencing towns with make-attribute:
<cities source=”not approved” dbxlink:eval=”remote”
dbxlink:transparent=”make-attribute insert-nodes”
xlink:href=”http://. . . /germantowns.xml#xpointer(//town)”/>
All referenced city elements are enriched with the local data items. However, in the virtual instance, an appropriate IDREFSattribute references the town elements:
<country cities=” dbxlinkID1 dbxlinkID2 . . . ”>
<name>Germany</name>
...
</country>
...
<town id=”dbxlinkID1” source=”not approved”>
<name>G¨ottingen</name>
<population>129051</population>
</town>
<town id=”dbxlinkID2” source=”not approved”>
<name>Braunschweig</name>
<population>245273</population>
</town>
...
If for this fragment the query
//country[@car code=’D’]/id(@cities)/@source
has to be evaluated, then it is obvious that the sourceattributes are not found remotely.
Thus, also for links with make-attribute which have local data it is not feasible to apply query shipping.
In this section, several examples showed why not to ship a query for links having local data and an “L”-directive different fromdrop-element. Also from the modeling perspec-tive it is inappropriate to ship a query in such situations because if a query has to be shipped for a link, we do not want to evaluate the link locally but expect the remote server to take care of this task.