Skip to main content

4. Data Model for Resource Properties (资源属性的数据模型)

4. Data Model for Resource Properties (资源属性的数据模型)​

4.1 The Resource Property Model (资源属性模型)​

Properties (属性) 是描述资源状态的数据片段。属性是关于数据的数据。

属性在分布式创作环境中用于提供资源的高效发现和管理。例如, 'subject' 属性可能允许按主题对所有资源进行索引, 而 'author' 属性可能允许发现哪些作者编写了哪些文档。

DAV 属性模型由名称/值对组成。属性的名称标识属性的语法和语义, 并提供引用其语法和语义的地址。

属性有两类: "live (活动)" 和 "dead (死亡)"。活动属性的语法和语义由服务器强制执行。活动属性包括以下情况: 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 属性都适用于属性值, 除非它已被更局部作用域的属性覆盖。请注意, 属性只有一个值, 使用一种语言 (或语言可以保持未定义); 属性不能有多种不同语言的多个值, 也不能有多种语言的单个值。

属性始终用由属性名称组成的 XML 元素表示, 称为 "property name element (属性名称元素)"。最简单的示例是空属性, 它不同于不存在的属性:

<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, 则不会识别这两个属性之间的任何关系。预计最终将产生一个单独的规范来解决与层次属性相关的问题。

最后, 不可能在单个资源上两次定义相同的属性, 因为这会导致资源属性命名空间中的冲突。

4.5 Source Resources and Output Resources (源资源和输出资源)​

某些 HTTP 资源由服务器动态生成。对于这些资源, 大概存在某处的源代码来控制该资源的生成方式。源文件与输出 HTTP 资源的关系可能是一对一, 一对多, 多对一或多对多。HTTP 中没有机制来确定资源是否是动态的, 更不用说其源文件存在于何处或如何创作它们。尽管解决此问题会很有用, 但可互操作的 WebDAV 实现已被广泛部署, 实际上并未解决此问题, 仅处理静态资源。因此, 源与输出问题在本规范中未得到解决, 已推迟到单独的文档中。

Last updated on