命名空间和控制器是什么关联
XML的核心功能之一是它具有处理数据规则变化的能力（因此，其名称具有可扩展性 -可扩展标记语言）。 随着对XML词汇表的更改，不可避免地要创建多个版本。 这使得有必要清楚地标记版本，以获取人和机器信息。 版本的清晰标记可用于驱动验证，或根据每个版本的要求进行分支处理。
您可以通过多种方式标记XML词汇表的版本。 本讨论着重于使用XML名称空间标记版本。
具有特殊属性或文档类型的版本控制
让我们从邮件标签格式的XML词汇开始：
清单1.邮件标签格式
<?xml version="1.0"?>
<labels>
<label>
<name>Thomas Eliot</name>
<address>
<street>3 Prufrock Lane</street>
<city>Stamford</city>
<state>CT</state>
</address>
</label>
</labels>如果我认为这种格式可能会更改，那么在我第一次部署它时就应该标记它的版本。 一种实现方法是通过文档类型声明（DTD）。 DTD引用了一个公共标识符，可以使其特定于文档版本。 一个很好的例子是W3C的XHTML公共标识符，用于以下声明中：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">您不仅可以看到版本（1.0），还可以看到版本内的变体（XHTML具有三种变体：严格，过渡和框架集）。
自然，各种版本的DTD本身都会反映所做的更改。 这种方法要求我在DTD中定义格式，但这可能并不总是需要的。 同样，尽管DOM和SAX提供了对源声明中使用的公共标识符的访问，但XSLT却没有。
经常使用的另一种方法是顶层版本属性。 例如：
清单2.具有版本属性的邮件标签格式
<?xml version="1.0"?>
<labels version="1.0">
<label>
<name>Thomas Eliot</name>
<address>
<street>3 Prufrock Lane</street>
<city>Stamford</city>
<state>CT</state>
</address>
</label>
</labels>无论我是否使用XML模式系统，顶级版本属性均有效。 并且可以从DOM，SAX，XSLT或任何其他常规XML处理技术中获得版本信息。
版本属性方法由XSLT语言本身采用。 这种方法的最大问题主要是概念上的：版本标识符和每个XML信息项之间的连接有些微弱（通常是通过祖先的属性，可能是遥远的属性）。 这还会导致根据版本调度的代码有些尴尬。
使用名称空间进行版本控制
为了使版本信息成为XML信息项的更直接属性，可以将它们放在反映版本的XML名称空间中。 例如：
清单3.具有名称空间版本的邮件标签格式
<?xml version="1.0"?>
<labels xmlns="http://uche.ogbuji.net/eg/labels/1.0">
<label>
<name>Thomas Eliot</name>
<address>
<street>3 Prufrock Lane</street>
<city>Stamford</city>
<state>CT</state>
</address>
</label>
</labels>因此，版本信息随名称空间一起传递-在每个SAX事件，每个DOM节点或每个XPath节点的名称空间轴上。 大多数W3C词汇表都使用此通用系统。 实际上，XSLT除版本属性外还使用它。
确切地说，W3C通常在名称空间URI中使用日期戳，而不是版本号。 我可以用以下内容来模拟：
清单4.具有日期标记的名称空间版本的邮件标签格式
<?xml version="1.0"?>
<labels xmlns="http://uche.ogbuji.net/eg/labels/2002/05">
<label>
<name>Thomas Eliot</name>
<address>
<street>3 Prufrock Lane</street>
<city>Stamford</city>
<state>CT</state>
</address>
</label>
</labels> 如清单4所示，当您使用命名空间进行版本控制时，最大的问题是，由于命名空间的传播，实际格式中即使是很小的更改也会成为一个大问题。 如果我调整格式以允许地址中包含可选的country元素，则用户最终将在所有处理过程中都支持原始名称空间以及更新后的名称空间（例如http://uche.ogbuji.net/eg/labels/1.0 ）代码，即使它可能对处理代码没有太大的实际影响。
如果版本中格式的更改很小，以至于不会对处理造成太大影响，则一种解决方案是不要在格式上的每一次更改都更改名称空间URI。 该解决方案在大多数情况下都有效，但是当名称空间的维护者使用可检索的URI指向描述该格式的实际文档时，该解决方案就会失效。 在这种情况下，文档可能会随格式的变化而变化，无论其大小如何。 因此，更改该文档的URI（也恰好是名称空间）是有意义的。
埃里克·范德VLIST提出了一个系统，在2001年3月的XML-DEV邮件列表上减少这一问题（参见相关主题 ）。
在这种情况下，版本号根据所表示格式更改的大小分为主要部分和次要部分。 名称空间中仅使用版本号的主要部分。 例如，我的邮件标签格式的原始版本是1.0（主要1，次要0）。 添加可选的国家/地区元素后，新版本为1.1（主要1，次要1）。 我在两种情况下都使用的命名空间是：
http://uche.ogbuji.net/eg/labels/1 然后，我设置HTTP服务器（该服务器提供每个命名空间URI指向的文档），以将用户从仅具有主要版本号的URL重定向到提供精确版本的URL。 因此，当服务器收到对http://uche.ogbuji.net/eg/labels/1的请求时，它将重定向到位于http://uche.ogbuji.net/eg/labels/1.1的文档，因为最新版本。 用户仍然可以通过对该URI进行显式请求来自由检索1.0文档。
结论
通过假定常规做法，本技巧可以掩盖几个有争议的观点。 使用名称空间标记版本比使用版本属性标记版本更为普遍，尽管哪种方法更好尚有争议。 同样，关于名称空间URI是否应该指向任何内容（由资源目录描述语言（RDDL）定义）直接指向定义格式的文档或有关词汇的常规信息文档，也存在争议。 同样，通常的做法是将HTTP URL用于名称空间。 考虑到本次讨论中所探讨的精妙之处，在实践中将版本放置在名称空间中已得到充分证明，并且使处理XML格式的更改变得有些麻烦。
翻译自: https://www.ibm.com/developerworks/xml/library/x-tipnamsp/index.html
命名空间和控制器是什么关联
扫一扫
814
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
