XML 스키마를 사용하여 요소(그림 및 텍스트)를 정의하는 기본 지식에 대한 자세한 설명

새로운 XML 스키마 시스템은 DTD의 한계(사이드바, DTD의 한계 참조)를 극복하고 XML 문서에 풍부한 문법 구조를 제공할 목적으로 W3C 권장 표준이 될 예정입니다. 이 기사에서는 스키마의 유연성을 보여주고 XML 스키마 시스템을 사용하여 XML 문서의 가장 기본적인 구성 요소인 요소를 정의하는 방법을 설명합니다.

XML 스키마는 DTD보다 강력합니다. XML 스키마 메커니즘의 강력한 기능을 설명하기 위해 다음 세 가지 프로그램 목록에서는 요소를 표현하는 다양한 방법을 간략하게 비교합니다. Listing 1은 XML 문서 세그먼트를 제공하고 Listing 2는 DTD 구문을 사용하여 이 두 요소를 선언하며 Listing 3은 해당 XML 스키마 구문 형식입니다. Listing 3에는 동일한 XML 구문이 사용되었습니다. 스키마를 통해 유효성 검사 구문 분석기는 InvoiceNo 요소가 양의 정수인지 여부와 ProductID 요소의 첫 번째 문자가 A부터 Z까지의 문자와 그 뒤에 6개의 아라비아 숫자가 오는지 여부를 확인할 수 있습니다. 대조적으로, DTD를 참조하는 유효성 검사 파서는 요소가 문자열로 표시되는지 여부만 확인할 수 있습니다.

목록 1: XML 문서 세그먼트

<InvoiceNo>123456789</InvoiceNo>
<ProductID>J123456</ProductID>

목록 2: 목록 1의 요소를 설명하는 DTD 세그먼트

<!ELEMENT InvoiceNo (#PCDATA)>
<!ELEMENT ProductID (#PCDATA)>

목록 3: 목록 1의 요소를 설명하는 XML 스키마

<element name=&#39;InvoiceNo&#39; type=&#39;positive-integer&#39;/>
<element name=&#39;ProductID&#39; type=&#39;ProductCode&#39;/>
<simpleType name=&#39;ProductCode&#39; base=&#39;string&#39;>
<pattern value=&#39;[A-Z]{1}d{6}&#39;/>
</simpleType>

XML 스키마에서 네임스페이스 사용

이 공동 작업 세계에서는 한 사람이 여러 다른 그룹의 문서에 대해 작업할 수 있고, 다른 그룹은 자신의 문서를 다른 방식으로 데이터 요소로 표현하려고 할 수 있습니다. 또한 서로 다른 그룹에서 만든 동일한 이름을 가진 문서의 요소를 참조할 수도 있습니다. 같은 이름의 다른 정의를 어떻게 구별하나요? XML 스키마는 네임스페이스를 사용하여 이러한 정의를 구별합니다.

첨부:

DTD의 한계

(DTD는 구조화된 정보를 기술하는 메커니즘으로 SGML 및 HTML 개발자에게 20년 동안 성공적으로 서비스를 제공했지만 XML 스키마와 비교하면,

DTD에서는 요소가 다음 세 가지 구성 요소로 구성되어야 합니다.

텍스트 문자열

텍스트 문자열과 다른 하위 요소의 혼합

하위 요소 집합

DTD는 XML 구문을 사용하지 않으며 유형 및 네임스페이스에 대해 제한된 지원만 제공합니다.

특정 XML은 다음과 같은 새 이름 집합을 정의합니다. 요소 이름, 유형 이름, 속성 이름 및 속성 그룹 이름 이러한 이름의 정의와 선언은 스키마에 기록됩니다. 목록 3에서는 InvoiceNo, ProductID 및 ProductCode를 포함한 이름을 정의합니다.

스키마에 정의된 이름은 대상 네임스페이스에 속한다고 말합니다. 네임스페이스 자체에는 URL 구문을 준수해야 하는 고정되었지만 제한되지 않은 이름이 있습니다. 예를 들어 목록 3의 스키마 섹션의 경우 네임스페이스 이름을 http://www.SampleStore.com/Account 로 지정할 수 있습니다.

네임스페이스 이름 구문은 http://로 시작하지만 해당 URL이 스키마 정의가 포함된 파일을 가리키지 않기 때문에 혼란스럽습니다. 실제로 URL http://www.SampleStore.com/Account는 어떤 파일도 가리키지 않고 단지 할당된 이름만 가리키고 있습니다.

스키마의 정의와 선언은 다른 네임스페이스에 속하는 이름을 참조할 수 있습니다. 이 문서에서는 이러한 네임스페이스를 소스 네임스페이스라고 부릅니다. 각 스키마에는 대상 네임스페이스가 있지만 소스 네임스페이스는 여러 개 있을 수 있습니다. 네임스페이스 이름은 상당히 길 수 있지만 xmlns 선언을 통해 XML 문서에서 약어를 사용할 수 있습니다. 이러한 개념을 설명하기 위해 위에서 언급한 목록 4의 예제 패턴에 조금 더 추가할 수 있습니다.

목록 4: 대상 네임스페이스 및 소스 네임스페이스

<!--XML Schema fragment in file schema1.xsd-->

<xsd:schema targetNamespace=&#39;http://www.SampleStore.com/Account&#39;
xmlns:xsd=&#39;http://www.w3.org/1999/XMLSchema&#39;
xmlns:ACC= &#39;http://www.SampleStore.com/Account&#39;>
<xsd:element name=&#39;InvoiceNo&#39; type=&#39;xsd:positive-integer&#39;/>
<xsd:element name=&#39;ProductID&#39; type=&#39;ACC:ProductCode&#39;/>
<xsd:simpleType name=&#39;ProductCode&#39; base=&#39;xsd:string&#39;>
<xsd:pattern value=&#39;[A-Z]{1}d{6}&#39;/>
</xsd:simpleType>

목록 4의 XML 스키마에서 targetNamespace의 이름은 InvoiceNo, ProductID 및 이름이 포함된 www.SampleStore.com/Account입니다. 제품코드. Schema , Element , simpleType , Pattern , string 및 positive-integer 이름은 소스 네임스페이스 www.w3.org/1999/XMLSchema 에 속하며 xmlns 선언을 통해 xsd로 축약됩니다. 별칭 xsd에는 특별한 것이 없으며 다른 이름을 선택할 수 있습니다. 이 기사 뒷부분에서는 편의와 단순성을 위해 xsd를 사용하여 네임스페이스 www.w3.org/1999/XMLSchema를 나타내고 일부 코드 조각에서는 xsd 한정자를 생략했습니다. 이 예에서는 ProductCode라는 이름을 사용하여 다른 이름이 정의되기 때문에 targetNamespace가 소스 네임스페이스 역할을 하는 경우가 있습니다.

목록 4의 패턴 섹션에서는 소스 패턴 파일의 위치를 ​​지정할 필요가 없습니다. 전체 "스키마 스키마"(http://www.w3.org/1999/XMLSchema)의 경우 해당 위치가 잘 알려져 있으므로 위치를 지정할 필요가 없습니다. 소스 네임스페이스 www.SampleStore.com/Account 의 경우 파일에 정의된 대상 네임스페이스이기 때문에 위치를 지정할 필요도 없습니다. 스키마 위치를 지정하고 기본 네임스페이스를 사용하는 방법을 더 잘 이해하려면 목록 5의 확장된 예제를 살펴보세요.

목록 5: 여러 소스 네임스페이스, 하나의 네임스페이스 가져오기

<!--XML Schema fragment in file schema1.xsd-->
<schema targetNamespace=&#39;http://www.SampleStore.com/Account&#39;
xmlns=&#39;http://www.w3.org/1999/XMLSchema&#39;
xmlns:ACC= &#39;http://www.SampleStore.com/Account&#39;
xmlns:PART= &#39;http://www.PartnerStore.com/PartsCatalog&#39;>
<import namespace=&#39;http://www.PartnerStore.com/PartsCatalog&#39;
schemaLocation=&#39;http://www.ProductStandards.org/repository/alpha.xsd&#39;/>
<element name=&#39;InvoiceNo&#39; type=&#39;positive-integer&#39;/>
<element name=&#39;ProductID&#39; type=&#39;ACC:ProductCode&#39;/>
<simpleType name=&#39;ProductCode&#39; base=&#39;string&#39;>
<pattern value=&#39;[A-Z]{1}d{6}&#39;/>
</simpleType>
<element name=&#39;stickyGlue&#39; type=&#39;PART:SuperGlueType&#39;/>

清单 5中多了一个名称空间引用： www.PartnerStore.com/PartsCatalog 。这个名称空间不同于 targetNamespace 和标准名称空间。因此必须使用 import 声明元素引入，该元素的 schemaLocation 属性指明包含模式的文件位置。默认的名称空间是www.w3.org/1999/XMLSchema ，它的 xmlns 声明没有名字。每个非限定的名字如 schema 和 element ，都属于默认名称空间www.w3.org/1999/XMLSchema 。如果模式从一个名称空间中引用了多个名字，将其指定为默认名字空间更方便。

一个 XML 实例文档可能引用多个名称空间的元素名，这些名称空间定义在不同模式中。为了引用和简化名称空间的名字，同样要使用 xmlns 声明。我们使用 XML Schema 实例名称空间的 schemaLocation 属性指定文件的位置。要注意，该属性不同于上一个例子中 xsd 名称空间的同名属性 schemaLocation 。

清单 6：使用来自多个模式的多个名称空间的名字

<?xml version="1.0"?>
<ACC:rootElement xmlns:ACC=&#39;http://www.SampleStore.com/Account&#39;
xmlns:PART=&#39;http://www.PartnerStore.com/PartsCatalog&#39;
xmlns:xsi=&#39;http://www.w3.org/1999/XMLSchema-instance&#39;
xsi:schemaLocation=&#39;http://www.PartnerStore.com/PartsCatalog
http://www.ProductStandards.org/repository/alpha.xsd
http://www.SampleStore.com/Account
http://www.SampleStore.com/repository/schema1.xsd&#39;>
<ACC:InvoiceNo>123456789</ACC:InvoiceNo>

图 2：清单 5 和清单 6 的名称空间

定义元素

定义元素就是定义元素的名字和内容模型。在 XML Schema 中，元素的内容模型由其类型定义，因此 XML 文档中实例元素的值必须符合模式中定义的类型。

类型包括简单类型和复杂类型。简单类型的值不能包含元素或属性。复杂类型可以产生在其他元素中嵌套元素的效果，或者为元素增加属性。（到目前为止本文中的例子都是用户定义的简单类型，比如 ProductCode ）。XML Schema 规范也包括预定义的简单类型（请参阅侧栏 简单类型）。 派生的简单类型约束了基类型的值。比如，派生简单类型 ProductCode 的值是基类型 string 值的子集。

简单的、非嵌套的元素是简单类型

不含属性或其他元素的元素可以定义为简单类型，无论是预定义的简单类型还是用户定义的简单类型，如 string 、 integer 、 decimal 、 time 、 ProductCode 等等。

清单 7：一些元素的简单类型

<element name=&#39;age&#39; type=&#39;integer&#39;/>
<element name=&#39;price&#39; type=&#39;decimal&#39;/>

带有属性的元素必须是复杂类型

现在，试着向 清单 7中的简单元素 price 增加属性 currency 。您不能这样做，因为简单类型的元素不能有属性。如果希望增加属性，您必须把 price 元素定义成复杂类型。在 清单 8的例子中，我们定义了一个 匿名类型，没有明确地命名这个复杂类型。换句话说，没有定义复杂类型 complexType 的 name 属性。

清单 8：一个复杂元素类型

<element name=&#39;price&#39;>
<complexType base=&#39;decimal&#39; derivedBy=&#39;extension&#39;>
<attribute name=&#39;currency&#39; type=&#39;string&#39;/>
</complexType>
</element>
<!-- In XML instance document, we can write: <price currency=&#39;US&#39;>45.50</price> -->

嵌入其他元素的元素必须是复杂类型

在 XML 文档中，一个元素可能嵌入其他的元素。这种要求可以在 DTD 中直接表示。但 XML Schema 定义一个元素，这个元素有一个类型，而这个类型可以包含其他元素和属性的声明。 表 1给出了一个简单的例子。

表 1：DTD 和 XML Schema 中复杂数据类型的比较

XML 文档

<Book>
<Title>Cool XML<Title>
<Author>Cool Guy</Author>
</Book>

DTD

<Book>
<Title>Cool XML<Title>
<Author>Cool Guy</Author>
</Book>

XML Schema

<Book>
<Title>Cool XML<Title>
<Author>Cool Guy</Author>
</Book>

尽管 表 1中的 XML 代码同时满足 DTD 与 XML Schema 段，但两者之间有一个很大的区别。在 DTD 中所有的元素都是全局性的，而表中的 XML Schema 允许把 Title 和 Author 定义成局部的——只出现在元素 Book 中。为了在 XML Schema 中实现与 DTD 声明完全相同的效果，元素 Title 和 Author 必须是全局范围的，如 清单 9中所示。元素 element 的 ref 属性使您能够引用前面声明的元素。

清单 9：用全局简单类型定义的复杂类型

<element name=&#39;Title&#39; type=&#39;string&#39;/>
<element name=&#39;Author&#39; type=&#39;string&#39;/>
<element name=&#39;Book&#39; type=&#39;BookType&#39;/>
<complexType name=&#39;BookType&#39;>
<element ref=&#39;Title&#39;/>
<element ref=&#39;Author&#39;/>
</complexType>

在 表 1和 清单 9所示的例子中， BookType 是全局性的，可用于声明其他元素。相反， 清单 10将该类型局部地定义到元素 Book 中，而且定义成匿名元素。要注意， 表 1中的 XML 文档段与表 1、 清单 9和 清单 10中三个模式段都匹配。

清单 10：隐藏 BookType 作为本地类型

<element name=&#39;Title&#39; type=&#39;string&#39;/>
<element name=&#39;Author&#39; type=&#39;string&#39;/>
<element name=&#39;Book&#39;>
<complexType>
<element ref=&#39;Title&#39;/>
<element ref=&#39;Author&#39;/>
</complexType>
</element>

表示元素的复杂约束

对于表示元素内容模型的约束，XML Schema 比 DTD 提供了更大的灵活性。在最简单的层次上，像在 DTD 中那样，您可以把属性和元素声明关联起来，指明能够出现的给定元素集合序列：只能出现 1 次（1）、出现 0 次或多次（*）或者出现 1 次或多次（+）。您还可以表示 XML Schema 中的其他约束，比方说使用 element 元素的 minOccurs 和 maxOccurs 属性，以及 choice 、 group 和 all 元素。

清单 11：表示元素类型的约束

<element name=&#39;Title&#39; type=&#39;string&#39;/>
<element name=&#39;Author&#39; type=&#39;string&#39;/>
<element name=&#39;Book&#39;>
<complexType>
<element ref=&#39;Title&#39; minOccurs=&#39;0&#39;/>
<element ref=&#39;Author&#39; maxOccurs=&#39;2&#39;/>
</complexType>
</element>

在 清单 11中， Book 中 Title 的出现是可选的（类似 DTD 的 '?'）。但是， 清单 11也说明 Book 元素中至少要有一个但不能超过两个作者。 element 的 minOccurs 和 maxOccurs 属性的默认值是 1。元素 choice 只允许它的一个子女出现在实例中。另外一个元素 all ，表示这样的约束：组中的所有子元素可以同时出现一次，或者都不出现，它们可以按任意的顺序出现。 清单 12表示 Title 和 Author 两者必须同时出现（顺序任意）在 Book 中，或者都不出现。这种约束很难在 DTD 中表示。

清单 12：指出必须为元素定义所有的类型

<xsd:element name=&#39;Title&#39; type=&#39;string&#39;/>
<xsd:element name=&#39;Author&#39; type=&#39;string&#39;/>
<xsd:element name=&#39;Book&#39;>
<xsd:complexType>
<xsd:all>
<xsd:element ref=&#39;Tile&#39;/>
<xsd:element ref=&#39;Author&#39;/>
</xsd:all>
</xsd:complexType>
</xsd:element>

更上层楼

我们已经讨论了在 XML Schema 中定义元素所需的最基本的概念，通过一些简单的例子使您领略到它的强大功能。还有一些更强大的机制：

XML Schema 对类型继承提供了广泛的支持，允许重用以前定义的结构。使用所谓的 facets，您可以派生新的类型，表示其他某个类型值的更小子集，比如通过枚举、范围或模式匹配来定义子集。在本文的例子中， ProductCode 类型就是使用模式面（ pattern facet）定义的。子类型也可以向基类型增加更多的元素和属性声明。

有几种机制控制能否定义子类型，或者能否在具体的文档中替换为子类型。比如，有可能表示 InvoiceType （ Invoice 编号的类型）不允许子类型化，任何人都不能定义新版本的 InvoiceType 。通过规定在特定的上下文中不能用 ProductCode 类型的子类型替换，也能表达这种约束。

除了子类型外，还可以定义等价的类型，这样，一个类型的值可以用另一个类型代替。

通过声明抽象的元素或者类型，XML Schema 提供了一种强制替换机制。

为了方便起见，可以定义并命名属性组和元素组，从而能够在后面引用这些组达到重用的目的。

XML Schema 提供了三个元素—— appInfo 、 documentation 和 annotation ——为模式作注解，以方便读者（ documentation ）和应用程序（ appInfo ）。

基于子元素的某些属性可以表示惟一性约束。

可以通过 W3C 站点（请参阅 参考资料）的文档进一步研究 XML Schema，或者访问 dW XML 专区了解更多的内容。目前，XML Schema 规范已经被批准，并成为候选推荐标准（Candidate Recommendation），毫无疑问您将越来越多地用到它。

위 내용은 XML 스키마를 사용하여 요소(그림 및 텍스트)를 정의하는 기본 지식에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!