xml-dev - Re: XLink - Assert linking relationships among more than two resource s

["Eve L. Maler" <elm@east.sun.com>]

At 01:46 PM 2/25/00 -0800, Hien Luu wrote:
>Hi All,
>
>I am looking for a way to maintain referential integrity between two
>different XML files.
>According to the XLink working draft, the XLink framework provides a
>mechanism to assert linking relationships among more than two resources.
>I am just curious if anyone has an example of how to do that using XLinK.
>
>Hien

Hello Hien,

I'm one of the XLink editors, and have also just developed/delivered a 
tutorial on XLink, and have a few examples I can share with you.  (I hope 
to add an example of 3+ participating resources to the spec.  Also, I hope 
to make my tutorial slides available sometime soon.)

Here is an example of a simple link that (by definition) contains the 
starting resource, and has (by definition) only one ending resource.  The 
arc goes from a word in the text of a recipe to a definition of the word.

...mixture of minced
<simpledef
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xlink:type="simple"
   xlink:href="caperDef.xml"
   xlink:show="new"
   xlink:actuate="onRequest">capers</simpledef> (about 1 tsp)...

Here is an extended link that accomplishes the same thing.  It has one 
local resource, one remote resource, and an explicitly specified arc that 
goes from the former to the latter.

...mixture of minced
<extendeddef
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xlink:type="extended">
   <word
     xlink:type="resource"
     xlink:role="wordInText">capers</word>
   <def
     xlink:type="locator"
     xlink:href="caperDef.xml"
     xlink:role="wordDefn" />
   <traverse
     xlink:type="arc"
     xlink:from="wordInText"
     xlink:to="wordDefn"
     xlink:show="new"
     xlink:actuate="onRequest" />
</extendeddef> (about 1 tsp)...

Here is an extended link that has the same local resource, but now it has 
two remote resources.  The arc element describes *two* arcs, with each 
starting at the local resource but going to a different remote ending 
resource.  The titles on the remote resources distinguish them, so that a 
user knows how to pick the one they want to traverse to.

...mixture of minced
<extendeddef
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xlink:type="extended">
   <word
     xlink:type="resource"
     xlink:role="wordInText">capers</word>
   <def
     xlink:type="locator"
     xlink:href="caperShortDef.xml"
     xlink:role="wordDefn"
     xlink:title="short definition" />
   <def
     xlink:type="locator"
     xlink:href="caperLongDef.xml"
     xlink:role="wordDefn"
     xlink:title="long definition" />
   <traverse
     xlink:type="arc"
     xlink:from="wordInText"
     xlink:to="wordDefn"
     xlink:show="new"
     xlink:actuate="onRequest" />
</extendeddef> (about 1 tsp)...

Finally, here is an extended link that has *no* local resources; it 
describes arcs between remote resources exclusively.  Whenever you have a 
starting resource that isn't local, you start needing the notion of 
linkbases and external linksets.

<!-- totally separate from the extendeddef element -->
...mixture of minced capers (about 1 tsp)...

<extendeddef
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xlink:type="extended">
<!-- assumes that "capers" we want is 4th occurrence -->
   <word
     xlink:type="locator"
     xlink:href='recipe.xml#xpointer(string-range(/,"capers")[4])'
     xlink:role="wordInText" />
   <def
     xlink:type="locator"
     xlink:href="caperShortDef.xml"
     xlink:role="wordDefn"
     xlink:title="short definition" />
   <def
     xlink:type="locator"
     xlink:href="caperLongDef.xml"
     xlink:role="wordDefn"
     xlink:title="long definition" />
   <traverse
     xlink:type="arc"
     xlink:from="wordInText"
     xlink:to="wordDefn"
     xlink:show="new"
     xlink:actuate="onRequest" />
</extendeddef>

I hope this series of examples is helpful, if a little more than you asked for!

         Eve
--
Eve Maler            Sun Microsystems
elm @ east.sun.com    +1 781 442 3190

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/threads.html
***************************************************************************