6.1 Restrictions on Query Shipping
6.1.3 Considering following-siblings and Position Checks
</country>
<country car code=”B” area=”30510”>
<name>Belgium</name>
<population>10170241</population>
<capital>
<name>Brussels</name>
<population year=”95”>951580</population>
</capital>
...
</country>
In order to summarize, we can state that we prohibit a shipping of a query if we have to combine the XPointer with a remaining query that contains the following axis because false nodes could be selected on the remote server and matching nodes in the local instance are mistakenly omitted.
6.1.3 Considering following-siblings and Position Checks
As we have seen in the previous section, a query that is shipped to the remote server can not “return” to the local instance for selecting matching nodes. This means that a query shipping usually delegates the remaining query computation on an XML subtree to another host. In case that the remaining query which will be part of the query to be shippedstarts with a step consisting of thefollowing-siblingaxis, the local siblings of the XML tree which replaces or enriches the link element have to be tested if they match the next step. Again, we use thecitieslink element as an example:
<country car code=”D” area=”356910”>
<name>Germany</name>
<population>83536115</population>
<cities dbxlink:eval=”remote” dbxlink:transparent=”drop-element insert-nodes”
xlink:href=”http://. . . /cities-D.xml#xpointer(/cities/city)”/>
...
</country>
Now, assume we have stated the following query for selecting the name of the cities that have a neighbor element among their following siblings:
//country[@car code=’D’]/city[following-sibling::neighbor]/name
If a remaining query starting with city[following-sibling::neighbor] would be shipped to the remote server that hosts the cities file for Germany, it would be executed after the XPointer has been evaluated – here, this would be an XML instance that does not contain any neighbor elements (cf. cities-D.xml in the distributed version of Mondial).
Thus, the returned query result would be empty because the predicate that contains the following-sibling axis would not be satisfied. On the other hand, we omitted matching elements locally. There areneighbor elements in the logical view that follow the German city elements and thus the predicate is satisfied by these (ignore by now thatneighboris an XLink itself):
<country car code=”D” area=”356910”>
<name>Germany</name>
<population>83536115</population>
<city>
<name>Berlin</name>
<population year=”95”>3472009</population>
</city>
...
<city>
<name>Jena</name>
<population year=”95”>102204</population>
</city>
<neighbor dbxlink:transparent=”. . . ” xlink:href=”. . . ” borderlength=”167”/>
...
</country>
Hence, we can not ship a query that starts with following-sibling because, similar to the case concerning thefollowingaxis, false nodes might be selected and relevant nodes could be omitted. Also, we prohibit shipping if the remaining query starts with a step that
contains a position expression. We then have to evaluate the remaining query locally because the position has to be evaluated wrt. the document order in the local view. The same holds for the context functionsposition() and last().
Note that the following-sibling axis and position checks are not harmful if they are not part of the next step to be executed. In that case, the tests take place in the context of the link’s subtree which has no local data and which can thus be located entirely on the remote server. All other axes (child, descendant(-or-self), attribute) are harmless if executed as part of the next step wrt. a considered link element. The reason for this is that, from the viewpoint of the XML tree, these axes either navigate to a deeper level in the referenced subtree (child and descendant(-or-self)) or are directly related to the current link element (attribute).
Remark. Consider the following query:
/countries/country[@car code=’D’]/descendant-or-self::node()/. . .
. . . /descendant-or-self::node()/following-sibling::country.
It consists of several steps “descendant-or-self::node()” applied to thecountryelement rep-resenting Germany. Due to the repeated implicit “self” step, thefollowing-sibling::country location step at the end of this query selects the country that follows Germany in docu-ment order. We also forbid such a usage offollowing-siblingfor queries to be shipped but for the sake of clarity, we don’t test these in the functioncanShipQuery(). However, it is just a technical issue to implement these kind of tests that have to analyze the given query syntactically.
Function 6.1: canShipQuery
Input: The link` and the remaining query parts (stepxandxpath-expr2).
Output: false, if the query can not be shipped, true otherwise.
begin
1
if xpath-expr2 is empty then
2
return false
3
else if ` has local data and`.getLDirective() 6=”drop-element” then
4
return false
5
else if stepx.predicate orxpath-expr2 contain followingthen
6
return false
7
else if stepx.predicate orxpath-expr2 start with following-siblingor position checks then
8
In this section, we have shown several restrictions on query shipping. These are checked in the functioncanShipQuery()wrt. a given user query and a current link to be resolved.
Remark. We assume that the remaining queryxpath-expr2 is not empty. Thus, only if the navigation continues on the referenced subtree, the query is shipped. Otherwise, it is preferable to apply any of the other shipping methods.
There are no other cases where query shipping has to be avoided but in some situations we have to rewrite the query. The related cases are discussed in the following section.