xml如何自动记录上次记录_划分有用的XML结构：XML中的地址记录

xml如何自动记录上次记录

XML已在信息处理中变得无处不在，从传统发布到业务交易再到Twitter，它都可以找到它的途径。 “ XML很简单！” “模因”通常意味着用于XML应用程序的标记集的设计对于信息集的实际使用而言可能常常不是最优的。 错误的信息设计会使操作和显示信息集所需的编码复杂化。 幸运的是，在开始时多做一些工作可以简化开发过程中的进一步工作。

常用缩略语

• IEC：国际电工委员会
• ISO：国际标准化组织
• SGML：标准通用标记语言
• W3C：万维网联盟
• XML：可扩展标记语言
• XSLT：可扩展样式表语言转换

设计信息结构可归结为三个基本问题：

• 信息集的有用部分是什么？
• 这些部分之间有什么关系？
• 您是否还想了解这些作品？

让我们检查一个公共信息集，并考虑在处理数据时可能使用的XML结构。

检查地址记录

地址记录以多种不同的形式和上下文出现：它本身可能出现在另一个信息集的中间，或者作为存储在数据库中以查询或打印为标签的集合的成员出现。 典型的地址记录可能类似于清单1 。

清单1.名称和地址记录

John Q. Public
1234 Main Street
Anytown, Anystate 54321-6789

从XML的角度来看，该结构可能与清单2一样简单。

清单2.带有简单标记的名称和地址记录

<address_rec>
  <line>John Q. Public</line>
  <line>1234 Main Street</line>
  <line>Anytown, Anystate 54321-6789</line>
</address_rec>

否则可能与清单3一样复杂。

清单3.具有复杂标记的名称和地址记录

<address_rec>
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
</address_rec>

您可以进一步细分此结构，标记标点符号（句点，逗号和连字符），也可以将邮政编码分为两部分。 您还可以添加信息，例如电话号码，传真号码，电子邮件地址或网站。

确定地址记录的要求

不过，停一会儿，并记住先前的基本问题。 有用的部分是什么？ 要确定这些内容，您首先需要确定对数据的要求和意图。 你会：

• 打印标签
• 按姓氏或邮政编码排序
• 搜索名称，城市或州

当您将数据分解成有用的部分时，计划如何使用数据可能会影响您做出的选择。 因此，分析信息集的第一步必须是确定关键需求。 定义一组容器（或从现有标准中选择一组）应由使用信息集的特定需求决定。 仅将表分解成行和列是不够的-关系表的记录结构可能无法捕获一些有用的分组。

信息集的要求通常可以分为三类：

• 一定有。 如果不满足这些要求，则该项目将失败。
• 很高兴有。 如果这些要求能够得到满足，您将能够为用户提供更多价值。
• 如果资源是无限的（“蓝天”选项）。 这些就是“酷”！ 可能超出当前项目范围的功能。

在当今的预算和截止日期下，必须具备的条件已经到位，一个项目也许可以选择其中一些需要具备的条件。 就是说，最好记录所有已确定的需求，甚至是Blue Sky需求。 一个团队可能认为“蓝天”要求可能是其中一项必备条件的副产品。

定义和完善地址记录模型

XML结构通常由元素和属性组成-在最基本的层次上， 元素是数据的容器， 属性是数据容器的标签。 首次为信息集构建XML模型时，将信息集定义为元素集合并使用属性优化元素结构通常很有用。

在地址记录示例中，简单结构和复杂结构都仅使用元素来表示。 您可以使用属性来优化和增强结构（例如，使用排序键）。 如果您开发自己的词汇表而不是采用标准词汇表，那么属性和元素名称的结构和选择完全取决于您。 使用元素或属性标识有用信息的决定受少数技术约束的支配，但除此之外，选择是完全灵活的。

查看上面清单3中更复杂的示例。 复杂的示例似乎可以满足到目前为止确定的所有要求：

• 您可以打印。 实际上，每个记录都可以在名称成分行上打印； 地址的街道部分的一条线； 以及用于地址的城市，州和邮政编码组成部分的行。
• 您已经识别了姓氏和邮政编码，因此可以使用这些元素的内容对address_rec组件进行排序。
• 您已经确定了名称及其组成部分以及城市和州，因此您可以搜索字符串并将匹配范围限制在这些元素之内。

您似乎已经满足了所有最初的要求。 尽管可能可以增强结构以适应将来的需求，但是现在您可以声明它已完成。 记住一句古老的格言：仅仅因为可以，并不意味着应该。

您如何改善结构？ 数据库像键一样，因此向每个address_rec组件添加一个记录键，如清单4所示 。

清单4.具有键属性的名称和地址记录

<address_rec key="1234">
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
</address_rec>

如果从数据库中提取记录以创建XML文档，则可以将数据库密钥直接传输到address_rec元素的key属性。 key属性用作address_rec容器上的标签，以提供记录的唯一标识符。

尽管您可能不想在假设的标签上打印电话号码，但是您可能会捕获其他类型的联系信息，这些信息可以转移到address_rec XML文档中。 您可以将电话号码和其他形式的电子联系信息合并为该结构的一部分，如清单5所示 。

清单5.带有其他联系信息的姓名和地址记录

<address_rec key="1234">
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
  <phone>316-555-1234</phone>
  <email>john@mydomain.com</email>
  <web>http://www.mydomain.com/john</web>
</address_rec>

如果您神话般的John Q. Public在计算机上花费的时间与我一样多，则他可能有多个联系点。 您可以为每个地址创建一个元素，或者使用具有限定属性的单个重复元素来标识其每个地址。 让我们尝试后者。 您还可以允许使用多个电话号码，如清单6所示 。

清单6.包含更多联系信息的姓名和地址记录

<address_rec key="1234">
  <name>
    <given_name>John</given_name>
    <middle>Q.</middle>
    <family_name>Public</family_name>
  </name>
  <address>
    <street>1234 Main Street</street>
    <city>Anytown</city>
    <state>Anystate</state>
    <zip_code>54321-6789</zip_code>
  </address>
  <phone type="home">316-555-1234</phone>
  <phone type="fax">316-555-1235</phone>
  <phone type="mobile">316-555-1236</phone>
  <web type="email">john@mydomain.com</web>
  <web type="email">john@myworkdomain.com</web>
  <web type="homepage">http://www.mydomain.com/john</web>
  <web type="twitter">johnqpublic</web>
</address_rec>

元素和属性名称的选择是任意的（除非您改用其他人的结构），类型属性的值也是如此。 名称和值的选择同样可以由为应用程序或系统确定的要求来驱动。

该过程中最重要的部分是满足要求：当您可以完成自己打算要做的事情时，您的工作就很可能完成了。

模式和验证：需求还是增强？

确定了信息集的有用部分并定义并完善了模型后，下一个要问的问题是：“我做完了吗？” 对于某些XML应用程序来说，标记有用的信息块并使用这些标记的块来驱动所需的任何后续处理就足够了。

到目前为止，您创建的是“格式正确”的XML文档：它们遵循的规则非常少，并且适用于许多不同类型的处理系统。 对于许多应用程序来说，可能只需要格式正确的XML文档。

但是，如果您的部分要求是遵循一套更严格的规则怎么办？ 可以验证XML文档（即，由程序根据一组更特定的规则和关系进行检查），并且您可以使用一种或多种形式验证语言编写用于验证的框架。 常见的验证语言是：

• 文档类型定义（DTD）。 DTD继承自SGML（ISO 8879，“标准通用标记语言”），是最古老的验证语言，并且被定义为W3C的XML Recommendation的一部分。
• W3C XML模式。 由W3C开发并广泛实施，该语言包含数据类型，并以XML文档形式编写。
• 放松NG。 RELAX NG由结构化信息标准组织（OASIS）开发，后来定义为ISO标准（ISO / IEC 19757-2：2008）的一部分，RELAX NG既有XML文档格式又有紧凑的非XML格式。

您可以在Schematron（一种基于XSLT的验证语言，用于验证文档内容和结构）中表达这些模式语言未涵盖的其他规则。

模式也可以是一种传达所需结构和关系的有用方法，尤其是对于诸如表单或创作工具之类的人机界面而言。 它代表了信息提供者和信息消费者之间的某种合同-“这就是我期望得到的，这就是我期望它如何组织的方式。”

验证不是基于XML的应用程序的必需部分，但它通常是控制XML文档创建或对从其他来源收到的XML文档进行质量控制的有用工具。

您需要架构吗？ 创建模式需要知识，时间和精力：如果它不是正在开发的应用程序或系统的有用部分，则很可能浪费资源。 请考虑以下准则：

• 您的信息机器是人为产生的还是人为产生的？ 模式是一种传达信息集的结构和内容要求的有用方法，尤其是与创作工具进行通信时。
• 信息是否来自您无法控制的来源？ 在这种情况下，该模式是一种确认外部信息源正在提供符合您希望接收的结构的XML文档的方式。
• 您需要验证吗？ 您的系统或客户端可能需要作为系统一部分的验证，而正式验证将需要一种或另一种形式的模式。
• 您的处理链中的工具是否需要架构？ 用于操纵或显示XML文档的工具可能不需要模式，但是编写工具可能会需要模式。

请记住，这句古老的格言在这里也适用：仅仅因为您可以 ，并不意味着您应该这样做。 在某些情况下，无需大量的工作就可能不需要，无用或什至不可能为特定信息集开发模式。 有用的架构偏爱数据相对可预测的应用程序-数据集的变化越大，架构就需要越复杂。

结论：信息分析简而言之

现在，划分XML信息集的有用部分的过程应该非常清楚：

1. 定义信息集的要求。
2. 检查信息集的样本。
3. 确定信息集的各个部分以及满足要求的部分之间的关​​系。

为XML应用程序打下坚实的基础可以减少对更聪明的（复杂的）编码的需求，这些编码在您的开发道路的更深处。

---

翻译自: https://www.ibm.com/developerworks/xml/library/x-divining/index.html

xml如何自动记录上次记录