4. Data Model for Resource Properties (Datenmodell für Ressourceneigenschaften)

4. Data Model for Resource Properties (Datenmodell für Ressourceneigenschaften)

4.1 The Resource Property Model (Das Ressourceneigenschaftsmodell)

Properties (Eigenschaften) sind Datenstücke, die den Zustand einer Ressource beschreiben. Eigenschaften sind Daten über Daten.

Eigenschaften werden in verteilten Autorenumgebungen verwendet, um eine effiziente Entdeckung und Verwaltung von Ressourcen zu ermöglichen. Beispielsweise könnte eine 'subject'-Eigenschaft die Indexierung aller Ressourcen nach ihrem Thema ermöglichen, und eine 'author'-Eigenschaft könnte die Entdeckung ermöglichen, welche Autoren welche Dokumente geschrieben haben.

Das DAV-Eigenschaftsmodell besteht aus Name/Wert-Paaren. Der Name einer Eigenschaft identifiziert die Syntax und Semantik der Eigenschaft und bietet eine Adresse, über die auf ihre Syntax und Semantik verwiesen werden kann.

Es gibt zwei Kategorien von Eigenschaften: "live" und "dead". Eine live-Eigenschaft hat ihre Syntax und Semantik, die vom Server durchgesetzt werden. Live-Eigenschaften umfassen Fälle, in denen a) der Wert einer Eigenschaft vom Server geschützt und gepflegt wird, und b) der Wert der Eigenschaft vom Client gepflegt wird, der Server jedoch eine Syntaxprüfung der übermittelten Werte durchführt. Alle Instanzen einer bestimmten live-Eigenschaft MÜSSEN der Definition entsprechen, die mit diesem Eigenschaftsnamen verbunden ist. Eine dead-Eigenschaft hat ihre Syntax und Semantik, die vom Client durchgesetzt werden; der Server zeichnet lediglich den Wert der Eigenschaft wörtlich auf.

4.2 Properties and HTTP Headers (Eigenschaften und HTTP-Header)

Eigenschaften existieren bereits in begrenztem Sinne in HTTP-Nachrichtenheadern. In verteilten Autorenumgebungen ist jedoch eine relativ große Anzahl von Eigenschaften erforderlich, um den Zustand einer Ressource zu beschreiben, und das Setzen/Zurückgeben aller über HTTP-Header ist ineffizient. Daher wird ein Mechanismus benötigt, der es einem Principal ermöglicht, eine Menge von Eigenschaften zu identifizieren, an denen der Principal interessiert ist, und nur diese Eigenschaften zu setzen oder abzurufen.

4.3 Property Values (Eigenschaftswerte)

Der Wert einer Eigenschaft ist immer ein wohlgeformtes XML-Fragment.

XML wurde gewählt, weil es ein flexibles, selbstbeschreibendes, strukturiertes Datenformat ist, das umfangreiche Schemadefinitionen unterstützt, und wegen seiner Unterstützung für mehrere Zeichensätze. Die selbstbeschreibende Natur von XML ermöglicht es, den Wert jeder Eigenschaft durch Hinzufügen von Elementen zu erweitern. Clients werden nicht brechen, wenn sie auf Erweiterungen stoßen, weil sie immer noch die im ursprünglichen Schema angegebenen Daten haben werden und Elemente ignorieren MÜSSEN, die sie nicht verstehen.

Die Unterstützung von XML für mehrere Zeichensätze ermöglicht es, jede menschenlesbare Eigenschaft in einem dem Benutzer vertrauten Zeichensatz zu codieren und zu lesen. Die Unterstützung von XML für mehrere menschliche Sprachen unter Verwendung des "xml:lang"-Attributs behandelt Fälle, in denen derselbe Zeichensatz von mehreren menschlichen Sprachen verwendet wird. Beachten Sie, dass der xml:lang-Geltungsbereich rekursiv ist, sodass ein xml:lang-Attribut auf jedem Element, das ein Eigenschaftsnamenselement enthält, auf den Eigenschaftswert angewendet wird, es sei denn, es wurde durch ein lokal begrenztes Attribut überschrieben. Beachten Sie, dass eine Eigenschaft nur einen Wert in einer Sprache hat (oder die Sprache KANN undefiniert bleiben); eine Eigenschaft hat nicht mehrere Werte in verschiedenen Sprachen oder einen einzelnen Wert in mehreren Sprachen.

Eine Eigenschaft wird immer durch ein XML-Element dargestellt, das aus dem Eigenschaftsnamen besteht, genannt "property name element". Das einfachste Beispiel ist eine leere Eigenschaft, die sich von einer nicht existierenden Eigenschaft unterscheidet:

<R:title xmlns:R="http://www.example.com/ns/"></R:title>

Der Wert der Eigenschaft erscheint innerhalb des Eigenschaftsnamenselements. Der Wert kann jede Art von wohlgeformtem XML-Inhalt sein, einschließlich reinem Text und gemischtem Inhalt. Server MÜSSEN die folgenden XML Information Items (unter Verwendung der Terminologie aus [REC-XML-INFOSET]) bei der Speicherung und Übertragung von dead-Eigenschaften beibehalten:

Für das Eigenschaftsname-Element Information Item selbst:

• [namespace name]
• [local name]
• [attributes] mit dem Namen "xml:lang" oder jedes solche Attribut im Geltungsbereich
• [children] vom Typ element oder character

Für alle Element Information Items im Eigenschaftswert:

• [namespace name]
• [local name]
• [attributes]
• [children] vom Typ element oder character

Für Attribute Information Items im Eigenschaftswert:

• [namespace name]
• [local name]
• [normalized value]

Für Character Information Items im Eigenschaftswert:

• [character code]

Da Präfixe in einigen XML-Vokabularen (z. B. XPath und XML Schema) verwendet werden, SOLLTEN Server für jedes Information Item im Wert beibehalten:

• [prefix]

XML Infoset-Attribute, die oben nicht aufgeführt sind, KÖNNEN vom Server beibehalten werden, aber Clients DÜRFEN NICHT darauf vertrauen, dass sie beibehalten werden. Die obigen Regeln würden auch standardmäßig für live-Eigenschaften gelten, sofern nicht anders definiert.

Server MÜSSEN das XML-Attribut xml:space ignorieren, falls vorhanden, und es niemals verwenden, um die Leerzeichenbehandlung zu ändern. Leerzeichen in Eigenschaftswerten sind signifikant.

4.3.1 Beispiel - Eigenschaft mit gemischtem Inhalt

Betrachten Sie eine vom Client wie folgt erstellte dead-Eigenschaft 'author':

<D:prop xml:lang="en" xmlns:D="DAV:">
  <x:author xmlns:x='http://example.com/ns'>
    <x:name>Jane Doe</x:name>
    <!-- Jane's contact info -->
    <x:uri type='email'
           added='2005-11-26'>mailto:[email protected]</x:uri>
    <x:uri type='web'
           added='2005-11-27'>http://www.example.com</x:uri>
    <x:notes xmlns:h='http://www.w3.org/1999/xhtml'>
      Jane has been working way <h:em>too</h:em> long on the
      long-awaited revision of <![CDATA[<RFC2518>]]>.
    </x:notes>
  </x:author>
</D:prop>

Wenn diese Eigenschaft angefordert wird, könnte ein Server zurückgeben:

<D:prop xmlns:D='DAV:'><author
        xml:lang='en'
        xmlns:x='http://example.com/ns'
        xmlns='http://example.com/ns'
        xmlns:h='http://www.w3.org/1999/xhtml'>
    <x:name>Jane Doe</x:name>
    <x:uri   added="2005-11-26" type="email"
      >mailto:[email protected]</x:uri>
    <x:uri   added="2005-11-27" type="web"
      >http://www.example.com</x:uri>
    <x:notes>
      Jane has been working way <h:em>too</h:em> long on the
      long-awaited revision of &lt;RFC2518&gt;.
    </x:notes>
  </author>
</D:prop>

Beachten Sie in diesem Beispiel:

• Das [prefix] für den Eigenschaftsnamen selbst wurde nicht beibehalten, da es nicht signifikant ist, während alle anderen [prefix]-Werte beibehalten wurden,
• Attributwerte wurden mit doppelten Anführungszeichen anstelle von einfachen Anführungszeichen neu geschrieben (Anführungsstil ist nicht signifikant), und die Attributreihenfolge wurde nicht beibehalten,
• das xml:lang-Attribut wurde auf dem Eigenschaftsnamenselement selbst zurückgegeben (es war im Geltungsbereich, als die Eigenschaft gesetzt wurde, aber die genaue Position in der Antwort wird nicht als signifikant betrachtet, solange es im Geltungsbereich ist),
• Leerzeichen zwischen Tags wurden überall beibehalten (Leerzeichen zwischen Attributen nicht),
• CDATA-Kapselung wurde durch Zeichen-Escaping ersetzt (das Gegenteil wäre auch legal),
• das Kommentarelement wurde entfernt (ebenso wie ein Processing-Instruction-Element).

Implementierungshinweis: Es gibt Fälle wie Bearbeitungsszenarien, in denen Clients verlangen können, dass XML-Inhalte Zeichen für Zeichen beibehalten werden (wie Attributreihenfolge oder Anführungsstil). In diesem Fall sollten Clients erwägen, einen reinen Texteigenschaftswert zu verwenden, indem sie alle Zeichen mit besonderer Bedeutung beim XML-Parsing escapen.

4.4 Property Names (Eigenschaftsnamen)

Ein Eigenschaftsname ist ein universell eindeutiger Bezeichner, der mit einem Schema verbunden ist, das Informationen über die Syntax und Semantik der Eigenschaft bereitstellt.

Da der Name einer Eigenschaft universell eindeutig ist, können Clients sich auf konsistentes Verhalten für eine bestimmte Eigenschaft über mehrere Ressourcen hinweg, auf demselben und über verschiedene Server hinweg verlassen, solange diese Eigenschaft auf den betreffenden Ressourcen "live" ist und die Implementierung der live-Eigenschaft ihrer Definition treu ist.

Der XML-Namespace-Mechanismus, der auf URIs ([RFC3986]) basiert, wird zur Benennung von Eigenschaften verwendet, da er Namespace-Kollisionen verhindert und unterschiedliche Grade der administrativen Kontrolle bietet.

Der Eigenschaften-Namespace ist flach; das heißt, keine Hierarchie von Eigenschaften wird explizit erkannt. Wenn also eine Eigenschaft A und eine Eigenschaft A/B auf einer Ressource existieren, wird keine Beziehung zwischen den beiden Eigenschaften erkannt. Es wird erwartet, dass schließlich eine separate Spezifikation erstellt wird, die Probleme im Zusammenhang mit hierarchischen Eigenschaften behandelt.

Schließlich ist es nicht möglich, dieselbe Eigenschaft zweimal auf einer einzigen Ressource zu definieren, da dies zu einer Kollision im Eigenschaften-Namespace der Ressource führen würde.

4.5 Source Resources and Output Resources (Quellressourcen und Ausgaberessourcen)

Einige HTTP-Ressourcen werden dynamisch vom Server generiert. Für diese Ressourcen existiert vermutlich irgendwo Quellcode, der regelt, wie diese Ressource generiert wird. Die Beziehung von Quelldateien zu Ausgabe-HTTP-Ressourcen kann eins zu eins, eins zu viele, viele zu eins oder viele zu viele sein. Es gibt keinen Mechanismus in HTTP, um zu bestimmen, ob eine Ressource überhaupt dynamisch ist, geschweige denn, wo ihre Quelldateien existieren oder wie sie zu erstellen sind. Obwohl dieses Problem sinnvoll gelöst werden könnte, wurden interoperable WebDAV-Implementierungen weithin eingesetzt, ohne dieses Problem tatsächlich zu lösen, indem nur mit statischen Ressourcen gearbeitet wurde. Daher wird das Quell- vs. Ausgabeproblem in dieser Spezifikation nicht gelöst und wurde auf ein separates Dokument verschoben.