メインコンテンツまでスキップ

4. Data Model for Resource Properties (リソースプロパティのデータモデル)

4. Data Model for Resource Properties (リソースプロパティのデータモデル)​

4.1 The Resource Property Model (リソースプロパティモデル)​

Properties (プロパティ) は, リソースの状態を記述するデータの断片です。プロパティはデータに関するデータです。

プロパティは, リソースの効率的な発見と管理を提供するために, 分散オーサリング環境で使用されます。たとえば, 'subject' プロパティは, すべてのリソースを主題別にインデックス化することを可能にし, 'author' プロパティは, どの著者がどのドキュメントを書いたかを発見することを可能にします。

DAV プロパティモデルは名前/値のペアで構成されます。プロパティの名前は, プロパティの構文とセマンティクスを識別し, その構文とセマンティクスを参照するアドレスを提供します。

プロパティには "live (ライブ)" と "dead (デッド)" の2つのカテゴリがあります。ライブプロパティは, その構文とセマンティクスがサーバーによって強制されます。ライブプロパティには次のケースが含まれます: a) プロパティの値がサーバーによって保護および維持される場合, b) プロパティの値がクライアントによって維持されるが, サーバーが送信された値に対して構文チェックを実行する場合。特定のライブプロパティのすべてのインスタンスは, そのプロパティ名に関連付けられた定義に準拠しなければなりません。デッドプロパティは, その構文とセマンティクスがクライアントによって強制されます; サーバーは単にプロパティの値を逐語的に記録します。

4.2 Properties and HTTP Headers (プロパティと HTTP ヘッダー)​

プロパティは, 限定的な意味で HTTP メッセージヘッダーにすでに存在しています。しかし, 分散オーサリング環境では, リソースの状態を記述するために比較的多数のプロパティが必要であり, それらすべてを HTTP ヘッダーを通じて設定/返すことは非効率的です。したがって, プリンシパルが関心のあるプロパティのセットを識別し, それらのプロパティのみを設定または取得できるようにするメカニズムが必要です。

4.3 Property Values (プロパティ値)​

プロパティの値は常に整形式の XML フラグメントです。

XML が選択されたのは, それが豊富なスキーマ定義をサポートする柔軟で自己記述的な構造化データ形式であり, 複数の文字セットをサポートしているためです。XML の自己記述的な性質により, 要素を追加することで任意のプロパティの値を拡張できます。クライアントは拡張に遭遇しても壊れません。元のスキーマで指定されたデータを引き続き持ち, 理解できない要素を無視しなければならないためです。

XML の複数文字セットのサポートにより, 人間が読める任意のプロパティをユーザーに馴染みのある文字セットでエンコードおよび読み取ることができます。XML の複数の人間の言語のサポートは, "xml:lang" 属性を使用して, 同じ文字セットが複数の人間の言語で使用される場合を処理します。xml:lang スコープは再帰的であるため, プロパティ名要素を含む任意の要素の xml:lang 属性は, より局所的にスコープされた属性によって上書きされない限り, プロパティ値に適用されることに注意してください。プロパティは1つの言語で1つの値のみを持つ (または言語が未定義のままである可能性がある) ことに注意してください; プロパティは異なる言語で複数の値を持つことも, 複数の言語で単一の値を持つこともできません。

プロパティは常に, "property name element (プロパティ名要素)" と呼ばれるプロパティ名で構成される XML 要素で表されます。最も単純な例は空のプロパティであり, これは存在しないプロパティとは異なります:

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

プロパティの値はプロパティ名要素の内部に表示されます。値は, テキストのみおよび混合コンテンツを含む, あらゆる種類の整形式 XML コンテンツである可能性があります。サーバーは, デッドプロパティの保存と送信において, 次の XML Information Items (情報項目) ([REC-XML-INFOSET] の用語を使用) を保持しなければなりません:

プロパティ名 Element Information Item (要素情報項目) 自体について:

  • [namespace name]
  • [local name]
  • [attributes] "xml:lang" という名前またはスコープ内のそのような属性
  • [children] 型が element または character

プロパティ値内のすべての Element Information Items (要素情報項目) について:

  • [namespace name]
  • [local name]
  • [attributes]
  • [children] 型が element または character

プロパティ値内の Attribute Information Items (属性情報項目) について:

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

プロパティ値内の Character Information Items (文字情報項目) について:

  • [character code]

プレフィックスは一部の XML ボキャブラリ (例えば XPath と XML Schema) で使用されるため, サーバーは値内の任意の Information Item (情報項目) について次を保持すべきです:

  • [prefix]

上記にリストされていない XML Infoset 属性はサーバーによって保持される可能性がありますが, クライアントはそれらが保持されることに依存してはなりません。上記の規則は, 特に定義されていない限り, デフォルトでライブプロパティにも適用されます。

サーバーは XML 属性 xml:space を存在する場合無視しなければならず, 空白処理を変更するためにそれを使用してはなりません。プロパティ値内の空白は重要です。

4.3.1 例 - 混合コンテンツを持つプロパティ​

クライアントによって次のように作成されたデッドプロパティ '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>

このプロパティが要求されると, サーバーは次を返す可能性があります:

<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>

この例で注意すべき点:

  • プロパティ名自体の [prefix] は重要ではないため保持されませんでしたが, 他のすべての [prefix] 値は保持されました,
  • 属性値は一重引用符ではなく二重引用符で書き換えられています (引用符のスタイルは重要ではありません), そして属性の順序は保持されていません,
  • xml:lang 属性はプロパティ名要素自体に返されました (プロパティが設定されたときにスコープ内にありましたが, レスポンス内の正確な位置はスコープ内にある限り重要とは見なされません),
  • タグ間の空白はすべての場所で保持されています (属性間の空白はそうではありません),
  • CDATA カプセル化は文字エスケープに置き換えられました (逆も合法です),
  • コメント項目は削除されました (処理命令項目も削除されます)。

実装ノート: クライアントが XML コンテンツを文字単位で保持する必要がある編集シナリオなどのケースがあります (属性の順序や引用符のスタイルなど)。この場合, クライアントは XML 解析で特別な意味を持つすべての文字をエスケープすることにより, テキストのみのプロパティ値を使用することを検討すべきです。

4.4 Property Names (プロパティ名)​

Property name (プロパティ名) は, プロパティの構文とセマンティクスに関する情報を提供するスキーマに関連付けられた普遍的に一意の識別子です。

プロパティの名前は普遍的に一意であるため, クライアントは, 同じサーバー上および異なるサーバー間の複数のリソースにわたって, 特定のプロパティの一貫した動作に依存できます。ただし, そのプロパティが問題のリソース上で "ライブ" であり, ライブプロパティの実装がその定義に忠実である場合に限ります。

XML namespace (名前空間) メカニズム (URIs ([RFC3986]) に基づく) は, 名前空間の衝突を防ぎ, さまざまな程度の管理制御を提供するため, プロパティの命名に使用されます。

プロパティ名前空間はフラットです; つまり, プロパティの階層は明示的に認識されません。したがって, プロパティ A とプロパティ A/B がリソース上に存在する場合, 2つのプロパティ間の関係は認識されません。階層プロパティに関連する問題に対処する別の仕様が最終的に作成されることが期待されています。

最後に, 単一のリソース上で同じプロパティを2回定義することはできません。これはリソースのプロパティ名前空間で衝突を引き起こすためです。

4.5 Source Resources and Output Resources (ソースリソースと出力リソース)​

一部の HTTP リソースはサーバーによって動的に生成されます。これらのリソースについては, そのリソースがどのように生成されるかを制御するソースコードがどこかに存在すると推定されます。ソースファイルと出力 HTTP リソースの関係は, 1対1, 1対多, 多対1, または多対多である可能性があります。HTTP には, リソースが動的であるかどうかを判断する, ましてやそのソースファイルがどこに存在するか, またはそれらをどのように作成するかを判断するメカニズムはありません。この問題は有用に解決されるでしょうが, 相互運用可能な WebDAV 実装は, 静的リソースのみを扱うことによって, 実際にはこの問題を解決せずに広く展開されています。したがって, ソース対出力の問題は本仕様では解決されておらず, 別のドキュメントに延期されています。

に最終更新