4.4 Modeling Directives for the relation Perspective
4.4.1 The dbxlink:transparent Directives for relation perspective . 35
Although the relation perspective is anchored to the linkbase (and thus is as-signed to the 3rd party), it is addressed first here, due to its similarity with the already familiar Simple Links modeling. In this manner, the modeling issues concerning Extended Links can be explained on basis of the “least abstract”
perspective, so that they are already familiar, and can be referred to during the sections covering theforwardand inverseperspectives.
Therelationperspective creates a modified view over the linkbase containing the Extended Link elements. Both from-locator and to-locator elements are expanded, the expansion results are concatenated (“from” first, “to” last). The concatenated result is combined with the traversed arc element, and finally, the expanded arcs are combined with the link element itself. In terms of perspective, relationresembles more of a complex kind of Simple Links: when link information is found inline, it is expanded in-place.
4.4.1 The dbxlink:transparent Directives for relation perspec-tive
The modeling directives forrelationare given in thedbxlink:transparentattributes of the arc element and the locator elements. The following modeling directives, marked up in Figure 4.7, apply:
• ext-L-dir determines how the surrounding Extended Link element is pro-cessed (duplicated, kept, dropped, etc.). As for a Simple Link’sL-directive,
(linkbase)
(arc)
•
a
(from document)
•
b
(todocument) Physical Instances
Virtual Instance
a b
relation
Figure 4.6: TherelationPerspective - Physical and Virtual Instance its possible values are: duplicate-element, group-in-element, drop-element, make-attribute, andkeep-body.
For duplicate-element, the Extended Link element is multiple times du-plicated and wrapped around every expanded arc and/or locator. The link element’s non-XLink nodes are duplicated with their parent, and the arc’s/locator’s result is inserted in document order right in the former position of the arc/locator.
Note thatext-L-dir is only relevant for therelationperspective. It has no meaning for eitherforwardor inverseperspectives.
• arc-L-dir determines how the arc element is processed (duplicated, kept, dropped, etc.). Again, its possible values are: dup-arc-elem, group-arc-elem,drop-arc-elem, make-arc-attr, andkeep-arc-body.
• from-L-dir and from-R-dir determine how the nodeset that is identified
4.4. MODELING DIRECTIVES FOR THERELATION PERSPECTIVE 37 by thefrom-locator is processed. As for Simple Links L-directive and R-directive, the possible values are: dup-from-elem, group-from-elem, drop-from-elem, make-from-attr,keep-from-body (from-L-dir) andins-from-elem, ins-from-bodies,ins-from-nothing (from-R-dir).
• to-L-dir andto-R-dir determine how the nodeset that is identified by the to-locatoris processed. It is exactly the same as for Simple Links. Hence, the possible values are: dup-to-elem,group-to-elem,drop-to-elem, make-to-attr, keep-to-body (to-L-dir) and ins-to-elem, ins-to-bodies, ins-to-nothing (to-R-dir).
• loc-L-dir andloc-R-dir are the left and right hand side directives for each locator. Note that in principle, each locator can be given the same map-ping functionality as a Simple Link. When traversed over an arc (which is the regular case), the arc’s from-L/R-dir/to-L/R-dir directives super-sede the locator’s own directives. But if a locator is traversed directly, the locator is expanded by its own L- and R-directive, just like a Simple Link. There is only one difference: to avoid unwanted expansion of loca-tors by accidentally traversing them (e.g. with imprecise XPath queries), a locator’s default transparent directive isdrop-element insert-nothing. So the locator won’t contribute anything (unwanted) to the virtual model, except explicitly stated different by the linkbase designer.
Since the linkbase is only directly accessed in relation perspective, a lo-cator’sdbxlink:transparentdirectives are only relevant for therelation per-spective. They have no meaning for theforwardandinverse perspectives, since those contribute to the virtual instance only by their arcs.
<ext dbxlink:transparent=’ext-L-dir’>
<arc xlink:type=’arc’>
<dbxlink:relation dbxlink:rolename=’rolename’
dbxlink:transparent=’card-dir arc-L-dir from-L-dir from-R-dir to-L-dir to-R-dir’/>
<dbxlink:forward dbxlink:rolename=’rolename’
dbxlink:transparent=’card-dir placement-dir arc-L-dir to-L-dir to-R-dir’/>
<dbxlink:inverse dbxlink:rolename=’rolename’
dbxlink:transparent=’card-dir placement-dir arc-L-dir from-L-dir from-R-dir’/>
arc content
</arc>
<loc xlink:type=’locator’
dbxlink:transparent=’loc-L-dir loc-R-dir’>
locator content
</loc>
</ext>
Figure 4.7: The directives forrelationperspective, marked in the link structure
Alloweddbxlink:transparentdirectives forrelation perspectivea:
arc-L from-L from-R to-L to-R
* * * * *
aThe star (*) stands for wildcard: for anL-dir, all fiveL-dirdirectives are allowed, for an R-dir, all threeR-dirdirectives are allowed.
Default values fordbxlink:transparentin relationperspective:
Simple Link L-dir R-dir drop-element insert-nodes
Extended Link element: ext-L-dir group-in-element Extended Link’s arc element arc-L-dir dup-arc-elem
from-L-dir from-R-dir drop-from-elem ins-from-nodes to-L-dir to-R-dir drop-to-elem ins-to-nodes Extended Link’s Locator element L-dir R-dir drop-element insert-nothing Example 5 To visualize the effect of the modeling directives from Example 4, look again at the parameters for therelationperspective: transparent=“dup-arc-elem drop-from-transparent=“dup-arc-elem ins-from-nodes drop-to-transparent=“dup-arc-elem ins-to-nodes”
• dup-arc-elem: the arc elementflight-conis kept, and is wrapped around the locator results4.
• drop-from-elem: the locator element cityref is dropped and replaced by the referenced node(s).
• ins-from-nodes: the referenced node(s) are completely inserted.
• drop-to-elem,ins-to-nodes: equivalent.
Result:
<linkbase>
<flightplan>
<flight-con>
<city id=“cty-NZ-wellington”>
<name>Wellington</name>
</city>
<city id=“cty-SI-singapore”>
<name>Singapore</name>
</city>
</flight-con>
</flightplan>
</linkbase>
Now consider the same relationship, still in the relationperspective, but let’s
assume now different mapping directives, given indbxlink:transparent: dbxlink:transparent=“dup-arc-elem dup-from-elem ins-from-bodies make-to-attr ins-to-nodes”
4Since both locations only yield a single node each, cardinality options have no effect.
4.4. MODELING DIRECTIVES FOR THERELATION PERSPECTIVE 39
• dup-arc-elem: again, the arc element flight-con is kept, and is wrapped around the locator results.
• dup-from-elem: the locator element cityref is kept, eventually duplicated (not here in the example) and inserted.
• ins-from-bodies: the referenced nodes’ bodies are are extracted and inserted into the surrounding element (here: the locator elementcityref.)
• make-to-attr ins-to-nodes: the referenced “to” element – here the city ele-ment of Singapore – is taken, and an IDREF attribute with the locator’s element name is created, referencing the Singapore element. For multi-ple result elements, an IDREFS attribute is created, containing a set of IDREF tokens, each one identifying one result element.
Result:
<linkbase>
<flightplan>
<flight-concity=“cty-SI-singapore”>
<cityref id=“cty-NZ-wellington”>
<name>Wellington</name>
</cityref>
</flight-con>
</flightplan>
. . .
<city id=“cty-SI-singapore”>
<name>Singapore</name>
</city>
. . .
</linkbase>
4.4.2 Cardinality Directives for relation
Algebraically, an arc defines a relationship between resources. Conceptually, a resource can be seen either as an atomic unit or as a multi-valued set of nodes (a nodelist). Following the latter concept, the arc – as a relationship – has a notion of cardinality. Like a relationship in Entity-Relationship Modeling for relational databases, an arc can relate two node sets as 1 : 1, 1 : n, n : 1 or m:nrelations.
1:1 means that the cartesian product of both nodesets is formed (the set of all ordered pairs with one item from nodeset A and one item from nodeset B). By convention, the node from the from-nodeset is first in document order, the node from the to-nodeset is second. The modeling directive is card-1-1.
1:n means that a from-node is followed by all to-nodes. This is done sequen-tially for all from-nodes. The modeling directive iscard-1-n.
m:1 similarly means that all from-nodes are followed by one to-node. Accord-ingly, this is done with all to-nodes. The modeling directive is card-m-1.
m:n simply concatenates the from-locator’s and to-locator’s results. The mod-eling directive is card-m-n.
See Figure 4.8 for illustration of the cases above. The cardinality directive is, just like all other modeling directives, denoted in the dbxlink:transparent attribute of the according dbxlink:relation child element of the concerned arc.
For later sections, please keep in mind that the cardinality aspect is as well of relevance for theforwardandinverseperspectives.
arc
a1 a2
(from-locator)
a3 b1
(to-locator) b2
1 : 1 cardinality
( a1 b1 )( a1 b2 )( a2 b1 )( a2 b2 )( a3 b1 )( a3 b2 )
1 :ncardinality ( a1 b1 b2 )( a2 b1 b2 )( a3 b1 b2 ) m: 1 cardinality ( a1 a2 a3 b1 )( a1 a2 a3 b2 )
m:ncardinality ( a1 a2 a3 b1 b2 )
Figure 4.8: Multi-valued locators mapped with different cardinalities
4.5 Modeling Directives for the forward and in-verse Perspectives
Theforwardperspective is anchored to thefrom-document, which means that a 3rd Party Link has an impact to a traversedfrom-document. The to-resource is combined with the arc information, and this intermediate result is blended into the from-document. In detail: the to-locator and the to-resource at the