6.3 Three Kinds of Transparency for 3rd Party Links
6.3.1 Concurrent View Definition
Within the Simple and 3rd Party Link-aware Addressing, it is possible to define arcs originating on nodes that have been added by other arcs itself: views over views over views can thus be created. Note that there is no natural order given over the arcs of a linkbase. If multiple arcs reference the same node, or a single
arc references a node via multiple from-locators (forward case) or multiple to-locators(inverse case), the view definition is calledconcurrent.
Concurrent view definitions are to some degree problematic for the XLink semantics, since there is no notion of an ”execution order” among the arcs or locators of a linkbase. If multiple arcs expand or modify the same node, what should be the result? For certain kinds of concurrent view definitions, conflict-free mappings can be thought of. Consider e.g. an element X, with multiple arcs enrichingX with ”insert” placement: all arcs could add their results to the body of elementX inside the virtual instance. But in which document order?
Or what, if one of the from-locators’XPointerexpression does no more address nodeX due to the modifications of one of the previous arcs? Even more obvious is the problem in the following constellation: two arcs reference nodeX as their from side, one with insert placement, one withreplace placement. Is node X first modified and then replaced? Or first replaced and then modified? In such situations, multiple ordering of mapping the arcs may result in multiple different results. Which ordering is the right one? And how to find it? Some approaches for finding the right mapping:
• find the “most conservative” mapping: from all combinatorially available mappings, take the mapping wich destroys the fewest information within the virtual instance. E.g. first evaluate arcs withreplacesemantics, then evaluate arcs with insertsemantics, then arcs withfusesemantics, etc.
• Postulate that the appearance of the arcs in the linkbase document deter-mines the order of the mapping: arcs coming first in document order are evaluated first.
• Evaluate the arcs in arbitrary ordering.
The first alternative – and this can already be guessed from the rather imprecise formulation – is not really formally definable, since (1) there is no canonical measure for information within a linkbase (at least, no trivial one), and (2) even supposing to have an efficiently computable (or heuristically approximated) canonical measure, many steps would involve problems as query containment, which often cannot be sufficiently solved with algorithmic methods. So, this alternative seems not to be an alternative at all.
The second alternative, taking the document order as mapping order, seems technically feasible, but relatively random, since it seems not quite evident how the rather technical aspect of the position of an arc in the linkbase should have any impact on the algebraic properties of the logical data model.
The third alternative is a generalization of alternative 2, and bears – seem-ing rather desperate than reasonable – few attraction, for similar reasons as alternative 2.
In absence of an intuitive and consistent interpretation of concurrent (and conflicting) view definitions, it seems reasonable to simply ignore concurrency in linkbases as invalid, leaving their evaluation to the application on a random or heuristic best-effort basis (indeed, in the general case it seems quite non-trivial
6.3. THREE KINDS OF TRANSPARENCY FOR 3RD PARTY LINKS 77 to decide upon the concurrency of a linkbase, since this involves – among other things – deciding about things like query containment).
Nevertheless it might be useful in certain scenarios to have multiple arcs referencing one node. ForSimple Link and 3rd-Party-Link-aware addressing, it is possible to explicitly declare a mapping order for the linkbase designer with means of the regular XLink semantics. Consider the following example, using thefuseplacement:
Example 7 Consider a linkbase with an arcc, two locatorsloc, from-document fromdoc.url and to-documenttodoc.urlin forwarddirection, with fusesemantics and1 : 1 cardinality:
<linkbase>
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-x” xlink:to=”get-y” strat=”1”/>
<loc xlink:label=”get-x” xlink:href=”fromdoc.url#xpointer(’//x’)”/>
<loc xlink:label=”get-y” xlink:href=”todoc.url#xpointer(’//y’)”/>
. . .
The fromdoc.urlinstance is expanded with the given arc c, producing the carte-sian product of the children of nodesx(from) and y(to):
fromdoc.url
1. Now, the linkbase is expanded with yet another arccand two more locators (the old, already evaluated parts are displayed ingray):
<linkbase>
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-x” xlink:to=”get-y” strat=”1”/>
<loc xlink:label=”get-x” xlink:href=”fromdoc.url#xpointer(’//x’)”/>
<loc xlink:label=”get-y” xlink:href=”todoc.url#xpointer(’//y’)”/>
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-c1” xlink:to=”get-z” strat=”2”/>
<loc xlink:label=”get-c1” xlink:href=”fromdoc.url#xpointer(’//c[@strat=”1”]’)”/>
<loc xlink:label=”get-z” xlink:href=”todoc2.url#xpointer(’//z’)”/>
. . .
Expanding againfromdoc.urlresults in the following virtual instance, pro-ducing the cartesian product of the three participating locators’ results, the children ofx,y, andz:
fromdoc.url . . .
<c strat=”1”><a/><b1/></c>
<c strat=”1”><a/><b2/></c>
⇒
fromdoc.url . . .
<c strat=”2”><a/><b1/><d1/></c>
<c strat=”2”><a/><b1/><d2/></c>
<c strat=”2”><a/><b2/><d1/></c>
<c strat=”2”><a/><b2/><d2/></c>
2. Now, a third arccis added to the linkbase, expanding the given set 3-tuples to a (even larger) set of 4-tuples:
<linkbase>
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-x” xlink:to=”get-y” strat=”1”/>
<loc xlink:label=”get-x” xlink:href=”fromdoc.url#xpointer(’//x’)”/>
<loc xlink:label=”get-y” xlink:href=”todoc.url#xpointer(’//y’)”/>
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-c1” xlink:to=”get-z” strat=”2”/>
<loc xlink:label=”get-c1” xlink:href=”fromdoc.url#xpointer(’//c[@strat=”1”]’)”/>
<loc xlink:label=”get-z” xlink:href=”todoc2.url#xpointer(’//z’)”/>
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-c2” xlink:to=”get-l” strat=”3”/>
<loc xlink:label=”get-c2” xlink:href=”fromdoc.url#xpointer(’//c[@strat=”2”]’)”/>
<loc xlink:label=”get-l” xlink:href=”todoc3.url#xpointer(’//l’)”/>
. . .
</linkbase>
fromdoc.url
<c strat=”2”><a/><b1/><d1/></c>
<c strat=”2”><a/><b1/><d2/></c>
<c strat=”2”><a/><b2/><d1/></c>
<c strat=”2”><a/><b2/><d2/></c>
. . .
todoc3.url . . .
<l><k1/></l>
<l><k2/></l>
Expanding again yields:
6.3. THREE KINDS OF TRANSPARENCY FOR 3RD PARTY LINKS 79
3. Now, a finally last arc x is added, producing the 5-tuple cartesian prod-uct over the sets of elements{a},{b1/b2},{d1/d2},{k1/k2} and{r}, re-moving the auxiliarystratattribute and re-installing the initialx element surrounding the generated tuples:
<linkbase>
. . .
<c dbxlink:transparent=”dup-arc-elem place-fuse card-1-1”
xlink:from=”get-last” xlink:to=”get-f” strat=”2”/>
<loc xlink:label=”get-last” xlink:href=”fromdoc.url#xpointer(’//c[@strat=”3”]’)”/>
<loc xlink:label=”get-f” xlink:href=”todoc4.url#xpointer(’//f’)”/>
. . .
• instead of creating a cartesian product over n sets, it is also possible to model with1 :ncardinality,addingnew nodes to a from-node’s body each time. Thereby, it is possible to model a sort of “sum” of nodes instead of a (cartesian) product.
• with thestrat( = stratum) attribute in the arc and in the locator’s XPointer, it is possible to explicitly define an “execution order” (or better: mapping priority) over a linkbase’s arcs. With this technique, it is possible for the linkbase designer to explicitly define a mapping order over the concurrent arc definitions, based alone on the proposed XLink semantics.