1.1 Geschichte und Ziele

Der Entwurf von XLink wurde von der Kenntnis vieler etablierter Hypermedia-Systeme und -Standards beeinflusst. Die folgenden Standards waren besonders einflussreich:

• HTML [HTML] definiert mehrere Elementtypen, die Links repräsentieren.

• HyTime [ISO/IEC 10744] definiert Strukturen für eingebettete, eingehende und Third-Party-Links sowie einige semantische Features, u.a. Traversierungskontrolle und Objektpräsentation.

• Text Encoding Initiative Guidelines [TEI] bietet Strukturen zum Erzeugen von Links, aggregierten Objekten und Linksammlungen.

Auch viele andere Link-Systeme haben zum Entwurf von XLink beigetragen, insbesondere [Dexter], [FRESS], [OHS], [MicroCosm] und [Intermedia].

Im Dokument über Anforderungen an XLink [XLREQ] finden Sie eine genaue Erläuterung von Anforderungen an den Entwurf von XLink.

2.1 Links und Ressourcen

[Definition: Ein XLink-Link ist eine explizite Beziehung zwischen Ressourcen oder Teilen von Ressourcen. ] [Definition: Sie wird durch ein XLink-Link-Element explizit gemacht, welches ein XLink-konformes XML-Element ist, das die Existenz eines Links ausdrückt. ] Es gibt sechs XLink-Elemente, von denen nur zwei als Link-Elemente angesehen werden. Die anderen liefern verschiedene Informationen, die die Eigenschaften eines Links beschreiben. (Der Begriff »Link«, so wie er in dieser Spezifikation benutzt wird, bezieht sich nur auf XLink-Links. Es spricht jedoch nichts dagegen, auch Nicht-XLink-Konstrukte als Links einzusetzen.)

Der Begriff Ressource hat im World Wide Web eine universelle Bedeutung. [Definition: Wie in [IETF RFC 2396] beschrieben, ist eine Ressource eine adressierbare Informations- oder Diensteinheit. ] Ressourcen sind zum Beispiel Dateien, Bilder, Dokumente, Programme und Anfrageergebnisse. Mittel zur Adressierung einer Ressource ist eine URI-Referenz (Uniform Resource Identifier Reference, näher beschrieben in 5.4 Adressangabe-Attribut (href)). Es ist möglich, einen Teil einer Ressource zu adressieren. Wenn es sich bei der gesamten Ressource zum Beispiel um ein XML-Dokument handelt, könnte der nützliche Teil dieser Ressource ein bestimmtes Element innerhalb des Dokuments sein. Das Verfolgen eines Links auf diesen Teil könnte z.B. dazu führen, dass das anvisierte Element hervorgehoben wird oder dass der Bildausschnitt an diese Stelle im Dokument verschoben wird.

[Definition: Wenn ein Link eine Menge von Ressourcen miteinander in Beziehung setzt, dann sagen wir, dass diese Ressourcen am Link teilnehmen.] Auch wenn XLink-Links in XML-Dokumenten vorkommen müssen, können sie alle möglichen Arten von Ressourcen miteinander verknüpfen, nicht nur XML-kodierte.

Eine der häufigsten Verwendungen von XLink besteht darin, Hyperlinks zu erzeugen. [Definition: Ein Hyperlink ist ein Link, der hauptsächlich für die Präsentation für einen menschlichen Benutzer gedacht ist.] Es gibt im Entwurf von XLink jedoch nichts, das dagegen spricht, XLink auch für Links zu benutzen, die nur für die Verarbeitung durch Computerprogrammen gedacht sind.

2.2 Kanten, Traversierung und Verhalten

[Definition: Das Benutzen oder Verfolgen eines Links zu welchem Zweck auch immer heißt Traversierung.] Auch wenn einige Arten von Links beliebig viele Ressourcen miteinander assoziieren können, beinhaltet die Traversierung stets nur ein Paar von Ressourcen (oder von Teilen der Ressourcen); [Definition: Die Quelle, von der aus die Traversierung beginnt, heißt Start-Ressource] und [Definition: das Ziel ist die End-Ressource]. Beachten Sie, dass der Begriff »Ressource« in diesem Zusammenhang auch einen Teil einer Ressource bezeichnen kann, nicht unbedingt die ganze Ressource.

[Definition: Informationen darüber, wie ein Paar von Ressourcen zu traversieren ist, inklusive der Traversierungsrichtung und möglichen Anwendungsverhaltens, nennen wir eine Kante]. Wenn zwei Kanten in einem Link dasselbe Ressourcen-Paar spezifizieren, und lediglich Start- und End-Ressource vertauscht sind, dann ist der Link multidirektional, was nicht dasselbe ist, wie einfach nach dem Traversieren eines Links »zurückzugehen«.

2.3 Ressourcen in Beziehung zum physikalischen Ort eines Link-Elements

[Definition: Eine lokale Ressource ist ein XML-Element, das dadurch an einem Link teilnimmt, dass entweder es selbst oder sein Vater ein Link-Element ist]. [Definition: Eine Ressource oder ein Teil einer Ressource, die an einem Link dadurch teilnimmt, dass sie durch eine URI-Referenz adressiert wird, nennen wir eine entfernte Ressource, selbst wenn sie im selben XML-Dokument wie der Link oder sogar im selben Link-Element liegt.] Anders ausgedrückt wird eine lokale Ressource »by value« und eine entfernte Ressource »by reference« angegeben.

[Definition: Eine Kante, die eine lokale Start- und eine entfernte End-Ressource hat, heißt ausgehend, d.h. sie geht fort vom Link-Element.] (Beispiele für Links mit solch einer Kante sind das HTML-A-Element, die »clinks« von HyTime und die XREF-Elemente der Text Encoding Initiative.) [Definition: Wenn die End-Ressource einer Kante lokal ist, aber die Start-Ressource entfernt, dann heißt die Kante eingehend.] [Definition: Wenn weder die Start- noch die End-Ressource lokal sind, heißt die Kante eine Third-Party-Kante.] Auch wenn dies nicht erforderlich ist, spezifiziert ein Link gewöhnlich nur durchgängig eine Art von Kanten, und kann daher als eingehender, ausgehender oder Third-Party-Link bezeichnet werden.

Um einen Link zu erzeugen, der von einer Ressource ausgeht, auf die man keinen Schreibzugriff hat (oder ausüben will), oder von einer Ressource, die keine Möglichkeit bietet, Link-Konstrukte einzubetten, ist es notwendig, eine eingehende oder Third-Party-Kante zu benutzen. Werden solche Kanten benutzt, stellt die Entdeckung des Links höhere Anforderungen als bei ausgehenden Kanten. [Definition: Dokumente, die Sammlungen von eingehenden Links und Third-Party-Links enthalten, werden Link-Datenbanken genannt, oder kurz Link-Banken.]

3.1 Verarbeitungsabhängigkeiten

XLink-Verarbeitung basiert auf [XML], [XML Names], [XML Base] und [IETF RFC 2396] (mit den Aktualisierungen aus [IETF RFC 2732]).

3.2 Markup-Konformität

Ein XML-Element ist XLink-konform, wenn:

1. es ein Attribut type aus dem XLink-Namensraum hat, dessen Wert entweder »simple«, »extended«, »locator«, »arc«, »resource«, »title« oder »none« ist und

2. es die durch den gewählten XLink-Elementtyp auferlegten Konformitätsbeschränkungen, wie durch diese Spezifikation vorgeschrieben, einhält.

Diese Spezifikation verhängt keine besonderen Beschränkungen für DTDs; Konformität bezieht sich nur auf Elemente und Attribute.

3.3 Anwendungskonformität

Eine XLink-Anwendung ist ein beliebiges Softwaremodul, das wohlgeformte XML-Dokumente interpretiert, welche XLink-Elemente und -Attribute enthalten, oder auch XML-Informationsmengen [XIS], die Informations-Items und -eigenschaften enthalten, welche XLink-Elementen und -Attributen entsprechen. (Dieses Dokument bezieht sich auf Elemente und Atttribute, aber alle hier gemachten Angaben gelten auch für die Entsprechungen aus dem Bereich der Informationsmengen). Solch eine Anwendung ist konform, wenn:

1. sie die in dieser Spezifikation aufgestellten zwingenden Bedingungen für Anwendungen erfüllt (»muss«) und

2. sie alle optionalen Bedingungen (»sollte« und »darf«), die sie zu erfüllen wünscht, auf die vorgeschriebene Weise erfüllt und

3. sie Markup-Konformitätstests entsprechend aller in dieser Spezifikation angegebenen Konformitätsbeschränkungen durchführt.

4.1 Verwendungsmuster von XLink-Attributen

Durch ihre Verwendung des Namensraum-Mechanismus gelten XLink-Attribute automatisch als global. Ihre erlaubten Kombinationen auf einem XLink-Element hängen aber stark ab vom Wert des speziellen Attributs type (für weitere Informationen siehe 5.3 Attribut zur Typfestlegung von XLink-Elementen (type)) des Elements, auf dem sie auftreten. Die Konformitätsbeschränkungen in dieser Spezifikation bestimmen die möglichen Verwendungsmuster. Es folgt eine Zusammenfassung der Elementtypen (Spalten), auf denen die globalen Attribute (Zeilen) erlaubt sind, die anzeigt, ob ein Wert angegeben werden muss (M) oder optional (O) ist:

(Siehe auch B Beispiel-DTD für eine nicht normative DTD, die die erlaubten Attributmuster illustriert.)

Diese Spezifikation benutzt die Konvention »Element vom Typ xxx«, um sich auf Elemente zu beziehen, die sich an eine benannte, mit einem XLink-Elementtyp verknüpfte Menge von Beschränkungen halten müssen, unabhängig davon, welchen Namen das Element tatsächlich hat. Zum Beispiel würde sich »Element vom Typ locator« auf alle folgenden Elemente beziehen:

<locator xlink:type="locator" ... /> 
<loc xlink:type="locator" ... />
<my:pointer xlink:type="locator" ... />

4.2 Beziehungen zwischen XLink-Elementtypen

Verschiedene XLink-Elementtypen haben spezielle, durch diese Spezifikation vorgeschriebene Bedeutungen, wenn sie als direkte Kinder anderer XLink-Elementtypen auftreten. Es folgt eine Zusammenfassung der Kindelementtypen, die für bestimmte Vaterelementtypen eine signifikante Rolle spielen (andere Kombinationen haben keine durch XLink vorgeschriebene Bedeutung):

4.3 Vorgabe von Attributwerten

Der Einsatz von XLink kann zur Folge haben, dass große Mengen von Attributen benutzt werden müssen, um wichtige Link-Informationen auszudrücken. In Fällen, in denen sich die Werte der gewünschten XLink-Attribute über individuelle Instanzen in allen Dokumenten eines bestimmten Typs hinweg nicht verändern, dürfen vorgegebene Attributwerte (fixed oder nicht) zur DTD hinzugefügt werden, so dass diese Attribute nicht mehr physisch auf den Element-Start-Tags auftreten müssen. Wenn zum Beispiel Attributwerte für die Attribute xmlns:xlink, xmlns:my, type, show und actuate im Beispiel in der Einleitung zu 4 Entwurf des XLink-Markup vorgegeben wären, würde das Beispiel wie folgt aussehen:

<my:crossReference 
  xlink:href="students.xml" 
  xlink:role="http://www.example.com/linkprops/studentlist" 
  xlink:title="Student List"> 
Current List of Students 
</my:crossReference>

Bei Informationsmengen, die unter Kontrolle einer DTD erzeugt wurden, sind alle Attributwerte automatisch aufgefüllt.

4.4 Integration von XLink-Einsatz mit anderem Markup

Diese Spezifikation definiert nur Attribute und Attributwerte im XLink-Namensraum. Es gibt keine Beschränkung für die Verwendung von N nicht-XLink-Attributen neben XLink-Attributen. Außerdem sind die meisten XLink-Attribute optional, und die Wahl zwischen einfachem und erweitertem Link liegt ganz beim Markup-Entwickler oder Dokument-Autor, so dass eine DTD, die XLink-Features verwendet, nicht den vollen Satz von Attributen von XLink benutzen oder deklarieren muss. Schließlich benennt diese Spezifikation nur die minimalen Beschränkungen für XLink-Markup. DTDs, die XLink verwenden, steht es frei, diese Beschränkungen zu verschärfen. Der Einsatz von XLink enthebt ein valides Dokument nicht davon, den in seiner bestimmenden DTD ausgedrückten Beschränkungen zu entsprechen.

Es folgt ein Beispiel für ein Element vom Typ crossReference mit sowohl XLink- als auch Nicht-XLink-Attributen:

<my:crossReference 
  xmlns:my="http://example.com/" 
  my:lastEdited="2000-06-10" 
  xmlns:xlink="http://www.w3.org/1999/xlink" 
  xlink:type="simple" 
  xlink:href="students.xml"> 
Current List of Students 
</my:crossReference>

4.5 Einsatz von XLink mit alten Dokumenten

Da die globalen Attibute von XLink die Nutzung von Namensraum-Präfixen erfordern, können nicht-XLink-basierte Links in alten Dokumenten im Allgemeinen nicht so, wie sie sind, als konforme XLink-Konstrukte dienen, selbst wenn Vorgaben für Attributwerte eingesetzt werden. So hat XHTML 1.0 zum Beispiel ein a-Element mit einem href-Attribut. Aber da dieses Attribut lokal an das a-Element im XHTML-Namensraum gebunden wurde, ist es nicht dasselbe wie ein globales xlink:href-Attribut des XLink-Namensraums.

5.1 Erweiterte Links (Element vom Typ extended)

[Definition: Ein erweiterter Link ist ein Link, der eine beliebige Anzahl von Ressourcen assoziiert. Die teilnehmenden Ressourcen dürfen eine beliebige Kombination aus entfernten und lokalen Ressourcen sein.]

Die einzige Art von Link, die in der Lage ist, eingehende und Third-Party-Kanten zu haben, ist der erweiterte Link. Üblicherweise werden erweiterte Links getrennt von den Ressourcen gespeichert, die sie assoziieren (zum Beispiel in einem ganz anderen Dokument). Erweiterte Links sind also immer dann wichtig, wenn die teilnehmenden Ressourcen nicht verändert werden können, oder wenn es teuer ist, die Ressourcen zu verändern und zu aktualisieren, es aber günstig ist, ein getrenntes Link-Element zu modifizieren und zu aktualisieren, oder wenn die Ressourcen in Formaten ohne Unterstützung für eingebettete Links vorliegen (wie z.B. viele Multimedia-Datenformate).

Das folgende Diagramm zeigt einen erweiterten Link, der fünf entfernte Ressourcen in Beziehung zueinander setzt. Dies könnte z.B. die Information über die Kurswahl eines Studenten repräsentieren: eine Ressource als eine Beschreibung des Studenten, eine andere als Beschreibung des Betreuers des Studenten, zwei Ressourcen als Repräsentation der Kurse, an denen der Student teilnimmt, und die letzte Ressource als Repräsentation eines Kurses, den der Student nur besucht.

Ohne den erweiterten Link stünden diese Ressourcen u.U. überhaupt nicht zueinander in Beziehung; z.B. könnten sie in fünf unterschiedlichen Dokumenten liegen. Die vom erweiterten Link ausgehenden Linien repräsentieren die Beziehungen, die durch ihn zwischen den Ressourcen erzeugt werden. Beachten Sie, dass die Kanten nicht gerichtet sind. Richtung wird durch Traversierungsregeln ausgedrückt; ohne Angabe von Traversierungsregeln werden die Ressourcen in keiner bestimmten Reihenfolge assoziiert, ohne zu implizieren, ob und wie auf einzelne Ressourcen zugegriffen wird

Das folgende Diagram zeigt einen erweiterten Link, der fünf entfernte und eine lokale Ressource (ein spezielles Element im erweiterten Link Element) assoziiert. Es könnte dieselbe Art von Kurswahl-Beispiel darstellen wie oben beschrieben, wobei zusätzlich der Numerus Clausus des Studenten lokal gespeichert wird. Wieder repräsentieren die Linien reine Beziehungen der sechs Ressourcen, ohne dass Traversierungsrichtungen oder -verhalten impliziert werden.

Der XLink-Elementtyp für erweiterte Links ist ein beliebiges Element mit einem Attribut type aus dem XLink-Namensraum, das den Attributwert »extended« hat.

Die Elemente vom Typ extended können beliebige Kombinationen der folgenden Elemente in beliebiger Reihenfolge enthalten, möglicherweise neben anderem Content und Markup:

• Elemente vom Typ locator, die die am Link teilnehmenden entfernten Ressourcen adressieren

• Elemente vom Typ arc, die die Traversierungsregeln zwischen den teilnehmenden Ressourcen des Links festlegen

• Elemente vom Typ title, die für Menschen lesbare Bezeichnungen für den Link bieten

• Elemente vom Typ resource, die am Link teilnehmende lokale Ressourcen beisteuern

Es ist kein Fehler, wenn ein Element vom Typ extended weniger als zwei Ressourcen assoziiert. Wenn der Link nur eine teilnehmende Ressource hat oder sogar gar keine, dann ist er einfach nicht traversierbar. Ein solcher Link kann immer noch nützlich sein, um z.B. mit Hilfe von XLink-Attributen Eigenschaften mit einer einzelnen Ressource zu assoziieren, oder um einen Platzhalter für Link-Information zu bieten, der später ausgefüllt wird.

Subelemente vom Typ simple oder extended irgendwo innerhalb eines Vaterelements vom Typ extended haben keine XLink-spezifizierte Bedeutung. Subelemente vom Typ locator, arc oder resource, die nicht direkte Kinder eines Elements vom Typ extended sind, haben keine XLink-spezifizierte Bedeutung.

Das Element vom Typ extended darf über die semantischen Attribute role und title verfügen (siehe 5.5 Semantische Attribute (role, arcrole und title)). Diese Attribute liefern semantische Information über den Link als Ganzes; das Attribut role beschreibt eine Eigenschaft, die dem gesamten Link zukommt, und das Attribut title ist eine für Menschen lesbare Beschreibung des gesamten Links. Wenn auf dem Element noch andere XLink-Attribute vorhanden sind, stehen sie in keiner XLink-spezifizierten Beziehung zu dem Link. Wenn sowohl ein Attribut title als auch ein oder mehrere Elemente vom Typ title vorhanden sind, stehen sie in keiner XLink-spezifizierten Beziehung. Eine auf XLink aufbauende Anwendung höherer Ebene wird in diesem Fall vermutlich ein angemessenes Verhalten spezifizieren wollen (z.B. Präzedens).

<!ELEMENT courseload ((tooltip|person|course|nc|go)*)>
<!ATTLIST courseload
  xmlns:xlink     CDATA           #FIXED "http://www.w3.org/1999/xlink"
  xlink:type      (extended)      #FIXED "extended"
  xlink:role      CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED>

<!ELEMENT tooltip ANY>
<!ATTLIST tooltip
  xlink:type      (title)         #FIXED "title"
  xml:lang        CDATA           #IMPLIED>

<!ELEMENT person EMPTY>
<!ATTLIST person
  xlink:type      (locator)       #FIXED "locator"
  xlink:href      CDATA           #REQUIRED
  xlink:role      CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED
  xlink:label     NMTOKEN         #IMPLIED>

<!ELEMENT course EMPTY>
<!ATTLIST course
  xlink:type      (locator)       #FIXED "locator"
  xlink:href      CDATA           #REQUIRED
  xlink:role      CDATA           #FIXED "http://www.example.com/linkprops/course"
  xlink:title     CDATA           #IMPLIED
  xlink:label     NMTOKEN         #IMPLIED>

<!-- NC = "Numerus Clausus" -->
<!ELEMENT nc ANY>
<!ATTLIST nc
  xlink:type      (resource)      #FIXED "resource"
  xlink:role      CDATA           #FIXED "http://www.example.com/linkprops/nc"
  xlink:title     CDATA           #IMPLIED
  xlink:label     NMTOKEN         #IMPLIED>

<!ELEMENT go EMPTY>
<!ATTLIST go
  xlink:type      (arc)           #FIXED "arc"
  xlink:arcrole   CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED
  xlink:show      (new
                  |replace
                  |embed
                  |other
                  |none)          #IMPLIED
  xlink:actuate   (onLoad
                  |onRequest
                  |other
                  |none)          #IMPLIED
  xlink:from      NMTOKEN         #IMPLIED
  xlink:to        NMTOKEN         #IMPLIED>

<courseload>

  <tooltip>Course Load for Pat Jones</tooltip>

  <person
    xlink:href="students/patjones62.xml"
    xlink:label="student62"
    xlink:role="http://www.example.com/linkprops/student"
    xlink:title="Pat Jones" />

  <person
    xlink:href="profs/jaysmith7.xml"
    xlink:label="prof7"
    xlink:role="http://www.example.com/linkprops/professor"
    xlink:title="Dr. Jay Smith" />
  <!-- weitere entfernte Ressourcen für Professoren, Assistenten etc. -->

  <course
    xlink:href="courses/cs101.xml"
    xlink:label="CS-101"
    xlink:title="Computer Science 101" />
  <!-- weitere entfernte Ressourcen für Kurse, Seminare etc. -->

  <nc xlink:label="PatJonesNC">1.7</nc>

  <go
    xlink:from="student62"
    xlink:to="PatJonesNC"
    xlink:show="new"
    xlink:actuate="onRequest"
    xlink:title="Pat Jones's Numerus Clausus" />
  <go
    xlink:from="CS-101"
    xlink:arcrole="http://www.example.com/linkprops/auditor"
    xlink:to="student62"
    xlink:show="replace"
    xlink:actuate="onRequest"
    xlink:title="Pat Jones, auditing the course" />
  <go
    xlink:from="student62"
    xlink:arcrole="http://www.example.com/linkprops/advisor"
    xlink:to="prof7"
    xlink:show="replace"
    xlink:actuate="onRequest"
    xlink:title="Dr. Jay Smith, advisor" />

</courseload>

<!ELEMENT nc ANY>
<!ATTLIST nc
  xlink:type      (resource)      #FIXED "resource"
  xlink:role      CDATA           #FIXED "http://www.example.com/linkprops/nc"
  xlink:title     CDATA           #IMPLIED
  xlink:label     NMTOKEN         #IMPLIED>

<nc xlink:label="PatJonesNC">3.5</nc>

<!ELEMENT person EMPTY>
<!ATTLIST person
  xlink:type      (locator)       #FIXED "locator"
  xlink:href      CDATA           #REQUIRED
  xlink:role      CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED
  xlink:label     NMTOKEN         #IMPLIED>

<!ELEMENT course EMPTY>
<!ATTLIST course
  xlink:type      (locator)       #FIXED "locator"
  xlink:href      CDATA           #REQUIRED
  xlink:role      CDATA           #FIXED "http://www.example.com/linkprops/course"
  xlink:title     CDATA           #IMPLIED
  xlink:label     NMTOKEN         #IMPLIED>

<person
  xlink:href="students/patjones62.xml"
  xlink:label="student62"
  xlink:role="http://www.example.com/linkprops/student"
  xlink:title="Pat Jones" />

<person
  xlink:href="profs/jaysmith7.xml"
  xlink:label="prof7"
  xlink:role="http://www.example.com/linkprops/professor"
  xlink:title="Dr. Jay Smith" />

<course
  xlink:href="courses/cs101.xml"
  xlink:label="CS-101"
  xlink:title="Computer Science 101" />

5.1.3 Traversierungsregeln für einen erweiterten Link (Element vom Typ arc)

Ein erweiterter Link darf Traversierungsregeln zwischen beteiligten Ressourcen mit Hilfe einer Folge von optionalen Kantenelementen festlegen.

Das XLink-Element für Kanten ist ein beliebiges Element mit einem Attribut type aus dem XLink-Namensraum, das den Attributwert »arc« hat.

Das Element vom Typ arc darf beliebigen Inhalt haben. Abgesehen von Elementen vom Typ title, die direkte Kinder sind (siehe 5.1.4 Titel für erweiterte Links, Adressangaben und Kanten (Element vom Typ title)), hat jeglicher vorhandener Inhalt keine XLink-spezifizierte Beziehung zu dem Link. Wenn das Element vom Typ arc etwas anderes als ein Element vom Typ extended zum Vater hat, dann hat dieses Element vom Typ arc keine XLink-spezifizierte Bedeutung.

Das Element vom Typ arc darf über die Traversierungsattribute from und to (siehe 5.7 Traversierungsattribute (label, from und to)), die Verhaltensattribute show und actuate (siehe 5.6 Verhaltensattribute (show und actuate)) und die semantischen Attribute arcrole und title (siehe 5.5 Semantische Attribute (role, arcrole und title)) verfügen.

Die Traversierungsattribute legen das gewünschte Verhalten beim Traversieren zwischen Paaren von Ressourcen fest, die am selben Link teilnehmen, wobei die Ressourcen durch den Wert ihres Attributs label identifiziert werden. Das Attribut from legt die Ressourcen fest, von denen die Traversierung begonnen werden darf (d.h. die Start-Ressourcen), während das Attribut to Ressourcen festlegt, zu denen traversiert werden darf (d.h. die End-Ressourcen). Die Verhaltensattribute legen das gewünschte Verhalten einer XLink-Anwendung bei der Traversierung zu der End-Ressource fest.

Die semantischen Attribute beschreiben die Bedeutung der End-Ressource der Kante relativ zu ihrer Start-Ressource. Das Attribut arcrole entspricht dem [RDF]-Begriff der Eigenschaft (property), wobei die Rolle so interpretiert werden kann, dass sie aussagt: »Start-Ressource HAT Rolle End-Ressource«. Die kontextuelle Rolle kann sich von der Bedeutung der End-Ressource unterscheiden, wenn diese außerhalb des Kontexts dieser bestimmten Kante betrachtet wird. So kann zum Beispiel eine Ressource generisch eine »Person« repräsentieren, jedoch im Kontext einer bestimmten Kante die Rolle der »Mutter« und im Kontext einer anderen Kante die Rolle der »Tochter« übernehmen.

Wenn dieselbe Ressource als Start-Ressource für mehrere Kanten dient (ob in einem einzelnen Link oder Link-übergreifend), wird das Traversierungsanfrageverhalten von dieser Spezifikation nicht beschränkt, aber eine Möglichkeit für interaktive Anwendungen wäre ein Pop-up-Menü, das alle relevanten Kanten- oder Link-Titel auflistet.

Das folgende Diagramm zeigt einen erweiterten Link, der fünf entfernte Ressourcen assoziiert und Regeln für die Traversierung zwischen ihnen bereitstellt. Alle spezifizierten Kanten sind Third-Party-Kanten; sie verlaufen ausschließlich zwischen entfernten Ressourcen. Die ungerichteten durchgezogenen Linien drücken wie vorher aus, dass der Link die fünf Ressourcen assoziiert; die neuen gestrichelten Pfeile visualisieren die Traversierungsregeln, die der Link bietet. Beachten Sie, dass sich einige Ressourcen den gleichen label-Wert teilen.

Das Diagram zeigt die gerichteten Traversierungskanten, die durch die folgenden Einstellungen erzeugt werden, wobei sowohl den As als auch den Cs erlaubt wird, die Traversierung zu allen Bs auszulösen. Da einige label-Werte auf mehreren Ressourcen auftreten, erzeugt jede Kantenspezifikation potenziell mehrere Traversierungskanten gleichzeitig:

<go xlink:type="arc" xlink:from="A" xlink:to="B" /> 
<go xlink:type="arc" xlink:from="C" xlink:to="B" />

Ein weiteres Beispiel: Nehmen wir einen erweiterten Link an, der fünf Adressangaben enthält, zwei mit dem label-Wert »parent« und drei mit dem label-Wert »child«:

<extendedlink xlink:type="extended"> 
   <loc xlink:type="locator" 
        xlink:href="..." 
        xlink:label="parent" 
        xlink:title="p1" /> 
   <loc xlink:type="locator" 
        xlink:href="..." 
        xlink:label="parent" 
        xlink:title="p2" /> 
   <loc xlink:type="locator" 
        xlink:href="..." 
        xlink:label="child" 
        xlink:title="c1"  /> 
   <loc xlink:type="locator" 
        xlink:href="..." 
        
        xlink:label="child" 
        xlink:title="c2"  /> 
   <loc xlink:type="locator" 
        xlink:href="..." 
        xlink:label="child" 
        xlink:title="c3"  /> 
   ... 
   <!-- Elemente vom Typ arc würden hier folgen. --> 
</extendedlink> 
      

Das folgende Fragment spezifiziert Traversierung von »parent«-Ressourcen zu »child«-Ressourcen, wozu p1-c1, p1-c2, p1-c3, p2-c1, p2-c2 und p2-c3 gehören:

<go xlink:type="arc" xlink:from="parent" xlink:to="child" />

Wenn für ein Attribut from oder to kein Wert angegeben ist, wird der fehlende Wert so interpretiert, dass er für alle label-Werte steht, die auf Elementen vom Typ locator in dem jeweiligen Element vom Typ extended angegeben sind. So spezifiziert das folgende Beispiel die Traversierungen von »parent«-Ressourcen zu »child«-Ressourcen und auch von »child«-Ressourcen zu »child«-Ressourcen, wozu p1-c1, p1-c2, p1-c3, p2-c1, p2-c2, p2-c3, c1-c1, c1-c2, c1-c3, c2-c1, c2-c2, c2-c3, c3-c1, c3-c2 und c3-c3 gehören:

<go xlink:type="arc" xlink:to="child" />

Beachten Sie, dass in diesem Fall zu den Traversierungsregeln auch Kanten von Ressourcen zu Ressourcen mit gleichem Label gehören (von »child« zu »child«) sowie von einigen Ressourcen zu sich selbst (von einem »child« zu sich selbst); das ist kein Fehler.

Wenn in einem erweiterten Link kein Element vom Typ arc angegeben ist, dann werden folgerichtig die fehlenden Attributwerte für from und to so interpretiert, dass sie für alle Label in diesem Link stehen. Dies wäre äquivalent zur folgenden Traversierungsspezifikation:

<go xlink:type="arc" />

Wenn mehr als ein Element vom Typ locator das gleiche Label hat, dann sind die locator mit dem gleichen Label als individuelle locator zu verstehen, nicht als Referenz auf eine aggregierte Ressource. Das Traversierungsverhalten eines solchen Links könnte das gleiche sein wie bei einem Link, in dem alle locator unterschiedliche Rollen haben und die passenden Kanten spezifiziert sind, um identische Traversierungspaare zu produzieren.

Wenn die Kantentraversierungsregeln für einen erweiterten Link irgendwelche möglichen Traversierungspaare auslassen, definiert XLink keine Traversierung für diese Paare. Eine Anwendung höherer Ebene darf jedoch nicht-XLink-gesteuerte Traversierungen ausführen; so könnte z.B. ein Link-Überprüfungsprozess alle verfügbaren Ressourcenpaare traversieren.

Beschränkung: Keine Kantenduplikation

Jedes Element von Typ arc muss ein Paar aus to- und from-Werten haben, das nicht die to- und from-Werte irgendeines anderen Elements vom Typ arc in demselben erweiterten Link wiederholt; d.h. jedes Paar in einem Link muss einzigartig sein.

Beispiel für Elementdeklarationen und -instanzen vom Typ arc

Es folgt eine nicht normative Menge von Deklarationen für ein Element vom Typ arc.

<!ELEMENT go EMPTY>
<!ATTLIST go
  xlink:type      (arc)           #FIXED "arc"
  xlink:arcrole   CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED
  xlink:show      (new
                  |replace
                  |embed
                  |other
                  |none)          #IMPLIED
  xlink:actuate   (onLoad
                  |onRequest
                  |other
                  |none)          #IMPLIED
  xlink:from      NMTOKEN         #IMPLIED
  xlink:to        NMTOKEN         #IMPLIED>

Es folgt ein Beispiel dafür, wie ein XML-Element aussehen könnte, das diese Deklaration benutzt:

<go
  xlink:from="student62"
  xlink:to="PatJonesNC"
  xlink:show="new"
  xlink:actuate="onRequest"
  xlink:title="Pat Jones's NC" />
<go
  xlink:from="CS-101"
  xlink:arcrole="http://www.example.com/linkprops/auditor"
  xlink:to="student62"
  xlink:show="replace"
  xlink:actuate="onRequest"
  xlink:title="Pat Jones, auditing the course" />
<go
  xlink:from="student62"
  xlink:arcrole="http://www.example.com/linkprops/advisor"
  xlink:to="prof7"
  xlink:show="replace"
  xlink:actuate="onRequest"
  xlink:title="Dr. Jay Smith, advisor" />

<!ELEMENT advisorname (name)> 
<!ATTLIST advisorname
  xlink:type      (title)         #FIXED "title"
  xml:lang        CDATA           #IMPLIED>

<!ELEMENT name (honorific?, given, family)> 
<!-- weitere Subelementdeklarationen für Namen -->

<advisor xlink:href="profs/jaysmith7.xml" ...>
  <advisorname xml:lang="en">
    <name>
      <honorific>Dr.</honorific>
      <given>Jay</given>
      <family>Smith</family>
    </name>
  </advisorname>
</advisor>

http://www.w3.org/1999/xlink/properties/linkbase

<!ELEMENT basesloaded ((startrsrc|linkbase|load)*)>
<!ATTLIST basesloaded
  xlink:type      (extended)      #FIXED "extended">

<!ELEMENT startrsrc EMPTY>
<!ATTLIST startrsrc
  xlink:type      (locator)       #FIXED "locator"
  xlink:href      CDATA           #REQUIRED
  xlink:label     NMTOKEN         #IMPLIED>

<!ELEMENT linkbase EMPTY>
<!ATTLIST linkbase
  xlink:type      (locator)       #FIXED "locator"
  xlink:href      CDATA           #REQUIRED
  xlink:label     NMTOKEN         #IMPLIED>

<!ELEMENT load EMPTY>
<!ATTLIST load
  xlink:type      (arc)           #FIXED "arc"
  xlink:arcrole   CDATA           #FIXED "http://www.w3.org/1999/xlink/properties/linkbase"
  xlink:actuate   (onLoad
                  |onRequest
                  |other
                  |none)          #IMPLIED
  xlink:from      NMTOKEN         #IMPLIED
  xlink:to        NMTOKEN         #IMPLIED>

<basesloaded>
  <startrsrc xlink:label="spec" xlink:href="spec.xml" />
  <linkbase xlink:label="linkbase" xlink:href="linkbase.xml" />
  <load xlink:from="spec" xlink:to="linkbase" actuate="onLoad" />
</basesloaded>

<basesloaded>
  <startrsrc
    xlink:label="spec"
    xlink:href="spec.xml#string-range(//*,'Click here to reveal annotations.')" />
  <linkbase xlink:label="linkbase" xlink:href="linkbase.xml" />
  <load xlink:from="spec" xlink:to="linkbase" actuate="onRequest" />
</basesloaded>

5.2 Einfache Links (Elemente von Typ simple)

[Definition: Ein einfacher Link ist ein Link, der genau zwei Ressourcen zueinander in Beziehung setzt, eine lokale und eine entfernte, mit einer Kante von der ersteren zur letzteren Ressource. Ein einfacher Link ist also immer ein ausgehender Link.]

Der Zweck eines einfachen Links besteht darin, eine bequeme Kurzschreibweise für den äquivalenten erweiterten Link zu bieten. Ein einziges einfaches Link-Element kombiniert die grundlegenden Funktionen eines Elements mit dem Typ extended, eines Elements mit dem Typ locator, eines Elements mit dem Typ arc und eines Elements mit dem Typ resource.

Das folgende Diagramm zeigt die Charakteristika eines einfachen Links; er assoziiert eine lokale und eine entfernte Ressource, und bietet implizit eine einzige Traversierungskante von der lokalen Ressource zur entfernten. Dies könnte z.B. den Namen eines Studenten repräsentieren, der in einem Text erscheint, der beim Anklicken zu Informationen über den Studenten führt.

<studentlink xlink:type="extended">
  <resource
    xlink:type="resource"
    xlink:label="local">Pat Jones</resource>
  <locator
    xlink:type="locator"
    xlink:href="..."
    xlink:label="remote"
    xlink:role="..."
    xlink:title="..." />
 
  <go
    xlink:type="arc"
    xlink:from="local"
    xlink:to="remote"
    xlink:arcrole="..."
    xlink:show="..."
    xlink:actuate="..." />
</studentlink>

Ein einfacher Link kombiniert alle obigen Features (außer den Typen und Labels) in einem einzigen Element. In Fällen, in denen nur eine Teilmenge der Features benötigt wird, steht das einfache Link-Element von XLink als Alternative zum erweiterten Link-Element zur Verfügung. Die folgenden Features fehlen bei einfachen Links:

• Angabe einer beliebigen Anzahl lokaler und entfernter Ressourcen

• Spezifikation einer Kante von der entfernten zur lokalen Ressource

• Zuweisung eines Titels zu der einen fest verdrahteten Kante

• Zuweisung einer Rolle oder eines Titels zu der lokalen Ressource

• Zuweisung einer Rolle oder eines Titels zu dem Link als Ganzem

Das XLink-Element für einfache Links ist ein beliebiges Element mit einem Attribut type aus dem XLink-Namensraum, das den Attributwert »simple« hat. Die einfache Entsprechung zum obigen erweiterten Link wäre wie folgt:

<studentlink xlink:href="...">Pat Jones</studentlink>

Das Element vom Typ simple darf beliebigen Inhalt haben. Das Element vom Typ simple selbst, zusammen mit seinem gesamten Inhalt, ist die lokale Ressource des Links, genau so, als wäre das Element vom Typ resource. Wenn ein Element vom Typ simple verschachtelte XLink-Elemente enthält, dann haben solche enthaltenen Elemente keine XLink-spezifizierte Beziehung zu ihrem Vater-Link. Es ist möglich, dass ein Element vom Typ simple keinen Inhalt hat; in Fällen, in denen man erwartet, dass der Link auf Anfrage zu traversieren ist, werden interaktive XLink-Anwendungen typischerweise Inhalt generieren, um dem Benutzer eine Möglichkeit zu bieten, die Traversierung auszulösen.

Das Element vom Typ simple übernimmt praktisch das Adressangabe-Attribut href sowie die semantischen Attribute role und title vom Element vom Typ locator und die Verhaltensattribute show, actuate und das einzige semantische Attribut arcrole vom Element vom Typ arc.

Es ist kein Fehler, wenn ein Element vom Typ simple keinen Adressangabe-(href)-Attributwert hat. Wird kein Wert angegeben, ist der Link einfach nicht traversierbar. Ein solcher Link kann dennoch nützlich sein, z.B. um mit Hilfe von XLink-Attributen der Ressource Eigenschaften zuzuweisen.

<!ELEMENT studentlink ANY>
<!ATTLIST studentlink
  xlink:type      (simple)        #FIXED "simple"
  xlink:href      CDATA           #IMPLIED
  xlink:role      NMTOKEN         #FIXED "http://www.example.com/linkprops/student"
  xlink:arcrole   CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED
  xlink:show      (new
                  |replace
                  |embed
                  |other
                  |none)          #IMPLIED
  xlink:actuate   (onLoad
                  |onRequest
                  |other
                  |none)          #IMPLIED>

... und <studentlink xlink:href="students/patjones62.xml">Pat
Jones</studentlink> ist in der Studentenverbindung sehr beliebt.

5.3 Attribut zur Typfestlegung von XLink-Elementen (type)

Das Attribut, das XLink-Elementtypen identifiziert, ist type.

Wenn das Attribut type den Wert »none« hat, hat das Element keine XLink-spezifizierte Bedeutung und jeglicher XLink-bezogene Inhalt und jegliche XLink-bezogenen Attribute haben keine XLink-spezifizierte Beziehung zu dem Element.

<!ATTLIST xlink:simple
  xlink:type      (simple)        #FIXED "simple"
  ...>

<!ATTLIST commandname
  xlink:type      (simple|none)   #REQUIRED
  xlink:href      CDATA           #IMPLIED>

5.4 Adressangabe-Attribut (href)

Das Attribut, das die Information liefert, mit der eine XLink-Anwendung eine entfernte Ressource (oder ein Ressourcen-Fragment) finden kann, heißt href. Es darf auf Elementen vom Typ simple verwendet werden und muss auf Elementen vom Typ locator verwendet werden.

Der Wert des href-Attributs muss eine URI-Referenz sein, wie sie in [IETF RFC 2396] definiert ist, oder muss nach Anwendung der unten beschriebenen escaping-Prozedur eine URI-Referenz ergeben. Die Prozedur wird angewendet, wenn die URI-Referenz einem URI-Resolver übergeben wird.

Einige Zeichen sind in URI-Referenzen nicht erlaubt, auch wenn sie in XML erlaubt sind; die nicht erlaubten Zeichen beinhalten alle Nicht-ASCII-Zeichen sowie die in Abschnitt 2.4 von [IETF RFC 2396] aufgelisteten ausgeschlossenen Zeichen, mit Ausnahme des Doppelkreuzzeichens (#) und des Prozentzeichens (%) und der eckigen Klammer, die in [IETF RFC 2732] wieder erlaubt wurden. Nicht erlaubte Zeichen müssen wie folgt ersetzt werden:

1. Jedes nicht erlaubte Zeichen wird nach UTF-8 [IETF RFC 2279] in ein oder mehrere Bytes konvertiert.

2. Bytes, die einem nicht erlaubten Zeichen entsprechen, werden mit dem URI-Ersetzungs-Mechanismus ersetzt (d.h. sie werden in %HH konvertiert, wobei HH die hexadezimale Notation des Byte-Werts ist).

3. Das Originalzeichen wird durch die resultierende Zeichenfolge ersetzt.

Da es für eine Anwendung nicht durchführbar ist, zu prüfen, ob ein Wert eine URI-Referenz ist, folgt diese Spezifikation in dieser Angelegenheit dem in [IETF RFC 2396] eingeschlagenen Pfad und erlegt XLink-Anwendungen keine solchen Anforderungen zur Konformitätsprüfung auf.

Wenn die URI-Referenz relativ ist, muss vor Verwendung mit der in [XML Base] beschriebenen Methode ihre absolute Adresse berechnet werden.

Für Adressangaben, die in XML-Ressourcen verweisen, wird das in der URI-Referenz verwendete Format für den Fragment-Identifikator (falls vorhanden) durch die XPointer-Spezifikation spezifiziert [XPTR].

<!ATTLIST simplelink
  xlink:href      CDATA           #REQUIRED
  ...>

5.5 Semantische Attribute (role, arcrole und title)

Die Attribute, die die Bedeutung von Ressourcen im Kontext eines Links beschreiben, sind role, arcrole und title. Das Attribut role darf auf Elementen mit dem Typ extended, simple, locator und resource verwendet werden. Das Attribut arcrole darf auf Elementen mit dem Typ arc und simple verwendet werden. Das Attribut title darf auf Elementen mit all diesen Typen verwendet werden.

Der Wert der Attribute role und arcrole muss eine URI-Referenz sein, wie in [IETF RFC 2396] definiert, mit der Einschränkung, dass der URI-Anteil absolut sein muss, falls das verwendete URI-Schema absolute und relative Formen gestattet. Die URI-Referenz identifiziert eine Ressource, die die intendierte Eigenschaft beschreibt. Wird kein Wert angegeben, so ist kein besonderer Rollenwert abzuleiten. In URI-Referenzen nicht erlaubte Zeichen in diesen Attributwerten müssen wie in 5.4 Adressangabe-Attribut (href) beschrieben speziell kodiert werden.

Das Attribut title wird benutzt, um die Bedeutung eines Links oder einer Ressource auf für Menschen lesbare Art zu beschreiben, ähnlich wie das role oder arcrole-Attribut (siehe allerdings auch 5.1.4 Titel für erweiterte Links, Adressangaben und Kanten (Element vom Typ title)). Ein Wert ist optional; wird ein Wert angegeben, so sollte er einen String enthalten, der die Ressource beschreibt. Die Verwendung dieser Information hängt sehr stark von der Art der vorgenommenen Verarbeitung ab. Sie darf z.B. benutzt werden, um Titel für Software für sehbehinderte Benutzer zur Verfügung zu stellen oder um ein Linkverzeichnis zu erstellen, oder um einen Hilfetext zu präsentieren, der erscheint, wenn der Benutzer den Mauszeiger über der Start-Ressource schweben lässt.

<!ATTLIST simplelink
          ...
          xlink:role      CDATA           #IMPLIED
          xlink:title     CDATA           #IMPLIED
          ...>

<!ATTLIST go
  ...
  xlink:arcrole   CDATA           #IMPLIED
  xlink:title     CDATA           #IMPLIED
  ...>

5.6 Verhaltensattribute (show und actuate)

Die Verhaltensattribute sind show und actuate. Sie dürfen in Elementen mit dem Typ simple und arc benutzt werden. Werden sie in einem Element vom Typ simple benutzt, geben sie das beabsichtigte Verhalten für die Traversierung zur einzigen End-Ressource dieses Links an. Werden sie auf ein Element vom Typ arc angewandt, geben sie das beabsichtigte Verhalten für die Traversierung zu sämtlichen End-Ressourcen (lokal oder entfernt) an, die durch diese Kante spezifiziert werden.

Die Attribute show und actuate müssen nicht angegeben werden. Werden sie benutzt, sollten konforme XLink-Anwendungen ihnen die in diesem Abschnitt spezifizierte Behandlung zukommen lassen. Es gibt keine harte Anforderung (»muss«) für diese Behandlung, denn es ist nicht anzunehmen, dass die für eine interaktive Anwendung wie z.B. einen Browser sinnvolle Behandlung auch für eine nicht interaktive Anwendung wie einen Roboter sinnvoll ist. Allerdings sollten alle Anwendungen die vollen Implikationen einer Abweichung vom spezifizierten Verhalten in Betracht ziehen, bevor sie einen anderen Weg einschlagen.

<!ATTLIST simplelink
  xlink:type      (simple)        #FIXED "simple"
  ...
  xlink:show      (new
                  |replace
                  |embed
                  |other
                  |none)          #IMPLIED
  xlink:actuate   (onLoad
                  |onRequest
                  |other
                  |none)          #IMPLIED
  ...>

Anwendungen, denen Elemente vom Typ arc in Link-Bank-Listen begegnen, müssen die Verhaltensattribute behandeln, als wenn sie als show="none" und actuate="onLoad" spezifiziert wären, selbst wenn andere Werte angegeben waren.

5.7 Traversierungsattribute (label, from und to)

Die Traversierungsattribute sind label (Etikett), from (von) und to (nach). Das Attribut label darf auf Elementen des Typs resource und locator benutzt werden. Die Attribute from und to dürfen auf Elementen des Typs arc benutzt werden.