Giới thiệu

Các định nghĩa kiểu đơn và phức trong lược đồ XML 1.0 cho phép các tác giả của lược đồ chỉ ra và giới hạn nội dung của thành phần và giá trị của thuộc tính. Theo đặc tả của lược đồ XML 1.0, các định nghĩa kiểu phức hợp ràng buộc các thành phần bằng cách cung cấp các mô tả thuộc tính mà điều khiển sự xuất hiện và nội dung của các thuộc tính bằng cách giới hạn các thành phần là rỗng hoặc làm cho phù hợp vói mô hình dữ liệu cụ thể, như là chỉ các thành phần (element-only), pha trộn, hoặc nội dung đơn được xác định bởi kiểu dữ liệu đơn của nội dung.

Định nghĩa kiểu dữ liệu phức hợp cũng như định nghĩa một cơ chế mà điều khiển một cấu trúc phân cấp định nghĩa kiểu xác định cách các kiểu dữ liệu phức hợp có thể thu được từ các kiểu dữ liệu phức hợp hoặc đơn khác bằng sự mở rộng hoặc giới hạn. Các nhóm thay thế trên kiểu dữ liệu phức hợp điều khiển sự thay thế của các thành phần với các thành phần mà kiểu dữ liệu của nó thu nhận được từ đó. Mặt khác, các kiểu dữ liệu đơn ràng buộc các giá trị ký tự của các nội dụng của các thành phần và các thuộc tính.

Trong bài viết này, chúng ta thảo luận về sự ràng buộc xuất hiện đồng thời, một thuộc tính mới được đưa ra trong lược đồ XML 1.1 để không chỉ ràng buộc nội dung của các thành phần và thuộc tính mà còn về sự tồn tại của chúng.

Lược sử

Như chúng tôi đã đề cập trong bài đầu tiên của loạt bài này, lược đồ XML có những giới hạn nhất định. Bên cạnh các ràng buộc nhắc đến ở trên, các tác giả của lược đồ XML thường cần củng cố các luật phức hợp hơn để xác định và giới hạn nội dung của các thành phần và thuộc tính, như là khả năng để giới hạn sự xuất hiện của các thành phần con cụ thể nào đó dựa trên giá trị của một thuộc tính, tổng số thành viên con không vượt quá một giá trị cụ thể, hoặc cho phép giá trị của một thành viên con có hiệu lực dựa trên phạm vi mà nó được tìm thấy.

Không may là lược đồ XML 1.0 không cho phép làm vậy. Để thực hiện những ràng buộc đó, có lẽ bạn phải

• Viết mã ở ứng dụng của bạn (sau khi xác nhận tính hợp lệ của lược đồ XML)
• Sử dụng bảng định kiểu để kiểm tra (như là một quá trình hậu kiểm)
• Sử dụng một ngôn ngữ lược đồ XML khác như là RelaxNG hoặc Schematron

Với yêu cầu liên tục cho ràng buộc đồng thời hỗ trợ kiểm tra từ cộng đồng người sử dụng lược đồ XML 1.0, nhóm phát triển lược đồ XML 1.1 đã giới thiệu khái niệm sự xác nhận (Assertions) và kiểu thay thế (type alternative) trong lược đồ XML 1.1 để cho phép tác giả lược đồ XML thể hiện những ràng buộc như vậy.

Sự xác nhận (Assertions)

Sự xác nhận cung cấp cho các tác giả của lược đồ XML một cách thức mềm dẻo để điều khiển sự xuất hiện và các giá trị của các thành phần và các thuộc tính.

Các tình huống sử dụng

Trước khi bạn đi sâu tìm hiểu các xác nhận được định nghĩa thế nào trong lược đồ XML 1.1, đầu tiên hãy xem qua các tình huống sử dụng chúng.

1. Đưa ra một luật ràng buộc dựa trên các giá trị của hai hay nhiều thuộc tính. Cho trước một phân mảnh XML trong Ví dụ 1, bạn có thể đưa ra một luật giữa các thuộc tính width và height sao cho chiều cao không bao giờ lớn hơn chiều rộng.
   
   Ví dụ 1. Một đoạn XML - thành phần với hai thuộc tính
   

   <dimension width="10" height="5"/>

   
   
2. Xác định một quy định ràng buộc giữa thuộc tính và thành phần. Trong Ví dụ 2, chúng ta có một thành phần mà có một thuộc tính và hai thành phần con. Bạn có thể đưa ra một quy định giữa một thuộc tính và các thành phần con sao cho giá trị của thuộc tính bằng số các thành phần con.
   
   Ví dụ 2. Một đoạn XML - thành phần với một thuộc tính và hai thành phần con
   

   <parent children="2"> <child name="one"/> <child name="two"/> </parent>

   
   
3. Đưa ra một quy định ràng buộc xác định thứ tự và lựa chọn giữa hai thuộc tính. Với thành phần được định nghĩa trong Ví dụ 3, bạn có thể đưa ra một quy ước trong đó timer có hoặc một thuộc tính time hoặc thuộc tính iterations nhưng không có cả hai.
   
   Ví dụ 3. Một đoạn XML - thành phần timer
   

   <timer time="30" iterations="2000"/>

   
   
4. Đưa ra một cách nhóm của các thành phần và thuộc tính vào một nhóm mô hình. Ví dụ, bạn có thể giới hạn nội dung của thành phần parent (định nghĩa trong Ví dụ 4), bằng cách đưa ra quy định bắt buộc nội dung của hoặc thành phần child (con) hoặc thành phần grandchild (cháu) và cả hai thành phần có các thuộc tính name (tên) và dob (ngày sinh).
   
   Ví dụ 4. Một đoạn XML - Một thành phần cha
   

   <parent> <child name="abc" dob="1/1/1997"/> <grandchild name="xyz" dob="1/1/2007"/> </parent>

   
   
5. Đưa ra một quy định ràng buộc về đoạn văn bản trong một thành phần với nội dung hỗn hợp. Trong Ví dụ 5 là một thành phần, parent, có nội dung hỗn hợp. Bạn có thể đưa ra một quy định cho phép nội dung hỗn hợp đó có độ dài tối đa là 10 ký tự.
   
   Ví dụ 5. Một đoạn XML - Một thành phần cha với nội dung hỗn hợp
   

   <parent>2 children <child>abc</child> <child>xyz</child> </parent>

   
   

Để giải quyết những những tình huống sử dụng này và những tình huống khác, lược đồ XML 1.1 cung cấp các ràng buộc hiệu quả hơn thông qua các xác nhận của lược đồ XML 1.1. Các xác nhận trong lược đồ XML 1.1 tương tự với những ràng buộc trong các ngôn ngữ lược đồ khác như là Schematron và RelaxNG.

Tại thời điểm viết bài này, bạn có thể chỉ rõ sự xác nhận trên các kiểu đơn và phức hợp. Các vị ngữ được chỉ rõ sử dụng một biểu thức XPath 2.0, biểu thức này là một phần của sự xác nhận được đưa ra trên kiểu dữ liệu này.

Sự xác nhận trên các kiểu dữ liệu phức hợp

Trong lược đồ XML 1.1, các định nghĩa kiểu phức hợp có thể chứa một dãy tuần tự các <xs:assert> là thành phần con của định nghĩa kiểu dữ liệu phức hợp. Thứ tự của chuỗi tuần tự là không quan trọng. Sự xác nhận ràng buộc của sự tồn tại của các thành phần và các thuộc tính với giá trị của chúng. Thành phần lược đồ <xs:assert> chứa một thuộc tính test là một bản ghi thuộc tính biểu thức XPath và một thuộc tính annotations.

Giá trị của thuộc tính test của mục thông tin thành phần xs:assert là một biểu thức XPath mà giá trị ước lượng trả về là đúng (true) hoặc sai (false). Bạn có thể sử dụng một biến đặc biệt, $value, đê tham chiếu đến giá trị nội dung đơn của thành phần hoặc thuộc tính đang được kiểm tra. Sự ước lượng được hoàn thành trong ngữ cảnh của thành phần cha. Biểu thức XPath phải là một biểu thức XPath 2.0 có hiệu lực hoặc ít nhất cũng đáp ứng tập con tối thiểu XPath được định nghĩa trong đặc tả lược đồ XML 1.1.

Nếu biểu thức XPath đưa ra không hiệu lực, một lỗi xpath-valid được thông báo. Nếu xs:assert được đưa ra không đúng, bộ xử lý lược đồ thông báo lỗi as-props-correct. Nếu sự ước lượng biểu thức điều kiện là đúng và không sinh ra lỗi, thành phần đó sẽ được xem là có hiệu lực cục bộ. Nếu giá trị biểu thức kiểm tra là sai, một lỗi chung chung cvc-assertion được trả về.

Ví dụ 6 đưa ra một ví dụ của một kiểu dữ liệu phức hợp với một sự xác nhận ràng buộc các giá trị của hai thuộc tính. Biểu thức xác nhận được đánh giá là true nếu giá trị của height nhỏ hơn giá trị của width, ngược lại là false.

<xs:element name="dimension">
  <xs:complexType>
    <xs:attribute name="height" type="xs:int"/>
    <xs:attribute name="width" type="xs:int"/>
    <xs:assert test="@height < @width"/>
  </xs:complexType>
</xs:element>

Trong ví dụ ở trên, chúng ta định nghĩa một mục thông tin thành phần xs:assert như là thành phần con trực tiếp của xs:complexType. Chúng ta cũng có thể chỉ rõ xs:assert trên xs:restriction hoặc xs:extension khi định nghĩa một kiểu phức hợp với nội dung phức hợp (xs:complexContent) hoặc nội dung đơn (xs:simpleContent). Để một thành phần là có hiệu lực, mỗi xác nhận trong chuỗi các xác nhận của nó cần được đánh giá là đúng. Chuỗi này được lập bởi tất cả các xác nhận được định nghĩa trên kiểu dữ liệu phức hợp cũng như tất cả các xác nhận của các kiểu dữ liệu phức hợp của thành phần tiền bối.

Trong Ví dụ 7, chúng ta có hai kiểu dữ liệu phức hợp, baseType và derivedType, mỗi kiểu có sự xác nhận của riêng nó. Sự xác nhận trên baseType kiểm tra nếu thuộc tính mustUnderstand có mặt trong thành phần. Sự xác nhận trên derivedType kiểm tra nếu thuộc tính mustUnderstand có một giá trị YES và ít nhất một thành phần con body có mặt; nếu không mustUnderstand sẽ có giá trị NO. derivedType có một chuỗi hai sự xác nhận, một cái từ baseType và một cái của chính nó. Để thành phần message có hiệu lực, nội dung của nó phải hiệu lực như được định nghĩa bởi định nghĩa complexType của nó và tất cả các xác nhận phải trả lại giá trị đúng.

<xs:complexType name="baseType">
  <xs:sequence>
   <xs:element name="body" minOccurs="0" maxOccurs="unbounded"/>
  </xs:sequence>
  <xs:attribute name="mustUnderstand" type="xs:string"/>
  <xs:assert test="@mustUnderstand"/>
</xs:complexType>

<xs:complexType name="derivedType">
  <xs:complexContent>
    <xs:restriction base="baseType">
      <xs:sequence>
        <xs:element name="body" minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:attribute name="mustUnderstand" type="xs:string"/>
      <xs:assert test="( @mustUnderstand eq 'YES' and fn:count(./body) > 0 )
                       or ( @mustUnderstand eq 'NO' )"/>
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

<xs:element name="message" type="derivedType"/>

Khi định nghĩa một kiểu phức hợp với nội dung đơn, bạn có thể chỉ rõ hai loại xác nhận. Loại đầu tiên hoạt động như sự xác nhận bề mặt (facet) và giới hạn kiểu nội dung đơn (ví dụ, giới hạn giá trị đơn là bội số của 7), trong khi cái thứ hai thực hiện sự xác nhận trên toàn bộ thành phần, bao gồm cả thuộc tính của nó. Khi cú pháp của mô hình nội dung của xs:simpleContent/xs:restriction không phân biệt giữa hai loại của sự xác nhận, một mục thông tin thành phần mới xs:assertion được giới thiệu để chỉ ra một sự xác nhận bề mặt. Chúng ta sẽ xem xét xs:assertion trong phần tiếp theo khi chúng ta bàn luận các sự xác nhận trên các định nghĩa kiểu đơn.

Sự xác nhận các kiểu đơn

Trong lược đồ XML 1.1, giống như các kiểu phức hợp, thành phần xs:restriction giữa các thành phần con của một xs:simpleType có thể chứa các thành phần xs:assertion. Các sự xác nhận các kiểu đơn tương đương với kiểu đơn khác ràng buộc xác nhận bề mặt. Thành phần kiểu dữ liệu đơn của sự xác nhận thể hiện một tập các ràng buộc bề mặt mà giới hạn giá trị của một kiểu đơn bằng cách yêu cầu các giá trị thỏa mãn các điều kiện được chỉ ra bởi biểu thức XPath trong giá trị của thuộc tính test.

Cũng giống như trong định nghĩa kiểu phức hợp, các sự xác nhận là một chuỗi có thứ tự của các thành phần xs:assertion được chỉ ra như là sự xác nhận bề mặt trong định nghĩa kiểu dữ liệu đơn. Thứ tự cụ thể của chuỗi các xác nhận là không quan trọng khi mà tất cả các xác nhận cần phải trả lại giá trị đúng để một thành phần hay một thuộc tính trở thành có hiệu lực. Thành phần lược đồ xác nhận chứa một thuộc tính giá trị là một chuỗi các xác nhận từ kiểu cơ sở, nếu có, và các xác nhận được định nghĩa trong simpleType.

Giá trị của thuộc tính test của thành phần xs:assertion là một biểu thức XPath 2.0 hoặc tập con của XPath 2.0 như được định nghĩa bởi đặc tả cả lược đồ XML 1.1 mà nó trả lại đúng hoặc sai. Sự ước lượng được thực hiện trong ngữ cảnh của thành phần cha. Một thành phần hay một thuộc tính với nội dung đơn là có hiệu lực nếu nó có hiệu lực với tất cả các xác nhận bề mặt (đó là, thuộc tính test của mỗi xs:assertion cho giá trị đúng, mà không có bất cứ lỗi gì.)

Trong Ví dụ 8, chúng tôi đưa ra một ví dụ của một thành phần với nội dung đơn giản mà có một xác nhận bề mặt trả lại giá trị đúng nếu giá trị của thành phần là bội số của 10.

<xs:element name="message">
 <xs:simpleType>
   <xs:restriction base="xs:int">
     <xs:assertion test="($value mod 10) = 0"/>
  </xs:restriction>
 </xs:simpleType>
</xs:element>

Một giá trị là có hiệu lực đối với một kiểu dữ liệu đơn được thừa hưởng mà giới hạn kiểu dữ liệu đơn khác, được cung cấp rằng nó thỏa mãn kiểu dữ liệu được thừa hưởng (và các xác nhận bề mặt giới hạn), và tất cả các xác nhận thuộc vào cả kiểu cơ sở và kiểu được thừa hưởng. Trong Ví dụ 9, một giá trị chuỗi là có hiệu lực nếu chỉ khi nó có 3 đến 25 ký tự và kết thúc bởi chuỗi "xyz".

<xs:simpleType name="base">
  <xs:restriction base="xs:string">
    <xs:maxLength value="25"/>
    <xs:assertion test="fn:ends-with($value, 'xyz')"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="derived">
  <xs:restriction base="base">
    <xs:assertion test="fn:string-length($value) > 3 "/>
  </xs:restriction>
</xs:simpleType>

Tùy biến thông điệp lỗi

Như được nêu ra ở các phần trước, các xác nhận của lược đồ XML 1.1 có thể sử dụng bất cứ biểu thức XPath 2.0 nào, và nhưng biểu thức này có thể rất phức tạp. Khi một xác nhận thất bại, các thông báo lỗi dễ hiểu trở lên vô cùng quan trọng.

Các mã lỗi của lược đồ

Khi một ràng buộc lược đồ bị xung đột, đặc tả lược đồ yêu cầu mã lỗi tương ứng được thông báo. Ví dụ, khi bạn nhìn thấy mã lỗi cvc-attribute.3, bạn hiểu rằng mệnh đề 3 của ràng buộc Attribute Locally Valid bị xung đột, điều đó chỉ ra rằng giá trị của một thuộc tính là không có hiệu lực đối với kiểu của nó.

Với một chút thông tin thêm về ngữ cảnh (ví dụ, tên thành phần hoặc thuộc tính, số dòng và số cột, hoặc các giá trị liên quan), mã lỗi này thường là đủ cho việc phân tích vấn đề. Áp dụng điều này vào các xác nhận, mã lỗi cvc-assertion sẽ được thông báo khi một xác nhận không được thỏa mãn. Thậm chí với tất cả các thông tin ngữ cảnh, bạn vẫn không hiểu nổi đã sai cái gì và làm thế nào để sửa, trừ khi bạn xem xét lược đồ đó và cố gắng tìm hiểu các biểu thức XPath (thường là vô cùng phức tạp).

Tiếp cận ngôn ngữ kiểm tra cấu trúc XML Schematron

Người sử dụng của ngôn ngữ kiểm tra cấu trúc XML Schematron (xem Tài nguyên) thường tìm thấy nó hữu dụng để tùy biến các thông điệp xảy ra khi các quy định bị xâm phạm (Ví dụ 10)

<report test="@min > @max">
  On element "<sch:value-of select="local-name(.)"/>", value of the
  "min" attribute "<sch:value-of select="@min"/>" can not be greater
  than that of the "max" attribute "<sch:value-of select="@max"/>".
</report>

Đoạn XML sau (Ví dụ 11) xâm phạm quy định này.

<range min="30" max="10"/>

Đoạn này sẽ sinh ra một thông báo: On element "range", value of the "min" attribute "30" can not be greater than that of the "max" attribute "10" (Một thành phần "range", giá trị của thuộc tính "min" "30" không thể lơn hơn giá trị của thuộc tính "max" "10").

Phương pháp tiếp cận này có hai lợi ích lớn:

1. Các thông điệp lỗi gần gũi với con người có thể được gắn với các quy định xác nhận, làm cho nó dễ phân tích sự thất bại của việc xác nhận.
2. Thông báo lỗi có thể sử dụng các XPath để tham chiếu đến các giá trị trong thể hiện đang được xác định để cung cấp nhiều thông tin hơn về nguyên nhân xung đột. Trong ví dụ trên, range, 30, và 10 là thông tin có thể thay đổi theo các thể hiện khác nhau.

Hỗ trợ địa phương hóa

Các quy định xác nhận có thể được triển khai trong các hệ thống ở các địa phương khác nhau, và người dùng muốn nhìn thấy các thông báo lỗi bằng ngôn ngữ của họ. Để thực hiện điều này, Schematron gợi ý sử dụng thuộc tính diagnostics trong sự gắn kết với thuộc tính xml:lang như trong Ví dụ 12.

<sch:pattern>
  <sch:rule context="person">
    <sch:assert test="name" diagnostics="d1 d2">
      A person must have a name.
    </sch:assert>
  </sch:rule>
</sch:pattern>

<sch:diagnostics>
  <sch:diagnostic id="d1" xml:lang="en">
    A person must have a name.
  </sch:diagnostic>
  <sch:diagnostic id="d2" xml:lang="fr">
    Une personne doit avoir un nom.
  </sch:diagnostic>
</sch:diagnostics>

Các cài đặt của Schematron bây giờ có thể lựa chọn diagnostic đúng dựa trên ngôn ngữ mong muốn.

Tiếp cận SML

Phương pháp tiếp cận Schematron vẫn chưa phải là hoàn hảo cho vấn đề địa phương hóa. Khi các từ ngữ mới được hỗ trợ, các quy định của Schematron phải được cập nhật, thêm vào điểm diagnostic mới, và thêm ID mới vào thuộc tính diagnostics.

Ngôn ngữ lập trình Java™ xử lý điều này bằng cách sử dụng các bó thuộc tính (property bundles). Khi một ngôn ngữ mới được thêm vào, một bó thuộc tính được đưa ra, và khi nó tuân theo quy ước viết tên, nó có thể được tìm thấy một cách tự động, mà không cần thay đổi nơi mà các thông báo được sử dụng.

Ngôn ngữ mô hình hóa dịch vụ (Service Modeling Language - SML) sử dụng Schematron như là một trong các cơ chế kiểm tra. Nó đưa ra khái niệm "ID vị trí" (location ID) (Ví dụ 13) để cho phép quản lý tài nguyên theo chiến lược giống như của môi trường Java.

<sch:assert test="name" sml:locid="person:nameRequired">
  A person must have a name.
</sch:assert>

Thuộc tính locid có kiểu QName. Tên của miền không gian tên của nó có thể được sử dụng để định vị bó thuộc tính (cái có thể chứa tất cả các thông báo lỗi liên quan đến một người), và local name để xác định thông báo lỗi để đưa ra với quy định tương ứng. Trong Ví dụ 14 và Ví dụ 15, chúng tôi đưa ra một vài ví dụ của các thuộc tính thông báo bằng tiếng Anh và tiếng Pháp.

nameRequired = A person must have a name.

nameRequired = Une personne doit avoir un nom.

Tùy biến thông báo lỗi cho các xác nhận

Lược đồ XML 1.1 không đưa ra cách để tùy biến các thông báo lỗi cho các xác nhận, nhưng nó cho phép áp dụng các thông tin cụ thể nhúng trong các chú thích. Ví dụ 16 chỉ ra cách để bao gồm một thông báo lỗi được tùy biến trong thành phần "appinfo" bên trong một chú thích và sử dụng "documentation" để cung cấp thông tin kèm theo về thông báo lỗi. Người dùng được lợi khi bộ xử lý lược đồ XML 1.1 thông qua một hành vi tốt nhất để sử dụng chú thích để tùy biến các lỗi xác nhận. Các thói quen thông dụng cũng có thể bao gồm các cơ chế để cho phép địa phương hóa các thông báo lỗi.

<xs:complexType name="rangeType">
  <xs:attribute name="min" type="xs:int"/>
  <xs:attribute name="max" type="xs:int"/>
  <xs:assert test="@min <= @max">
    <xs:annotation>
      <xs:appinfo>
        Value of the "min" attribute can not be greater than that of the "max"
        attribute.
      </xs:appinfo>
      <xs:documentation>
        When this assertion fails, the content of the above "appinfo" is used
        to produce the error message.
      </xs:documentation>
    </xs:annotation>
  </xs:assert>
</xs:complexType>

Các kiểu dữ liệu thay thế (Type alternatives)

Lược đồ XML 1.1 giới thiệu một cơ chế mới tên là kiểu thay thế dữ liệu (type alternatives) cho phép tác giả của lược đồ chỉ ra sự thay thế kiểu trên một mô tả của thành phần.

Phép gán kiểu có điều kiện

Trong lược đồ XML 1.0, xsi:type đã được giới thiệu như là một cơ chế cho việc thay thế kiểu. xsi:type được đưa ra trên một thành phần trong một tài liệu để thay thế kiểu được khai báo với một kiểu được thừa hưởng. Cơ chế này hoạt động tốt nếu bạn đặc biệt thiết kết một từ vựng XML để sử dụng với lược đồ XML và bạn yêu cầu các thể hiện đó của từ vựng của bạn sử dụng xsi:type cho sự thay thế kiểu. Nếu, tuy nhiên, bạn viết một lược đồ XML cho một bộ từ vựng mà nó có sẵn ký hiệu của việc thay thế dữ liệu, thì xsi:type sẽ không hoạt động. Thể hiện của từ vựng này lựa chọn các kiểu sử dụng một cơ chế khác nào đó. Một ví dụ như vậy là định dạng cung cấp thông tin Atom (Atom Syndication Format), một ngôn ngữ XML được sử dụng cho các trang web điểm tin.

Atom cho phép các thể hiện chỉ ra một thuộc tính type trên một thành phần chứa cấu trúc văn bản. Nếu tồn tại, giá trị của thuộc tính này phải là một trong text, html hoặc xhtml. Nội dung được phép được xác định bởi giá trị của thuộc tính này. Bởi vì thuộc tính này không là xsi:type, nên hoàn toàn có thể viết một lược đồ mô hình hóa Atom sử dụng ngôn ngữ lược đồ XML 1.0. Nếu điều kiện lựa chọn kiểu phức tạp hơn, ví dụ @height < @width (so sánh giá trị của hai thuộc tính), bạn không thể thay thế nó trong thể hiện này với xsi:type.

Để giải quyết sự thiếu sót của xsi:type, bạn có thể sử dụng cơ chế thay đổi type. Điều này cho phép tác giả của lược đồ đưa ra kiểu thay thế trên một mô tả thành phần được lựa chọn dựa trên sự đánh giá biểu thức XPath. Trong phần tiếp theo chúng tôi sẽ giới thiệu cách làm việc của nó sử dụng Atom như là một ví dụ.

Thay đổi kiểu dữ liệu làm việc thế nào

Trong lược đồ XML 1.1, các mô tả thành phần có thể có một bảng chứa một chuỗi các thành phần kiểu thay thế và một định nghĩa kiểu mặc định (cũng là một kiểu thay thế). Trong một tài liệu lược đồ XML những cái này được chỉ rõ như là một chuỗi của thành phần con xs:alternative của sự mô tả thành phần. Thành phần lược đồ kiểu thay thế chứa một thuộc tính test là một bản ghi thuộc tính biểu thức XPath, một định nghĩa kiểu, và một thuộc tính annotations.

Giá trị của thuộc tính test trên xs:alternative tương ứng với thuộc tính test, một biểu thức XPath đánh giá đúng hoặc sai. Biểu thức được cho phép bị giới hạn trong tập con của XPath 2.0, cụ thể là những biểu thức lựa chọn trục thuộc tính. Điều này có nghĩa rằng chỉ những thuộc tính trên thành phần hiện tại là có thể truy cập được bởi đánh giá XPath. Cần lưu ý rằng mô hình dữ liệu XDM được xây dựng cho sự đánh giá không bao hàm thông tin về kiểu. Điều này được thực hiện để tránh tình huống khi một trình xử lý lược đồ cần dự đoán các kiểu của các thành phần nhằm mục đích xác định kiểu của thành phần. Không thể biết một kiểu thực sự của một thuộc tính cho đến khi kiểu của nó được xác định.

Thành phần con cuối cùng xs:alternative của mô tả thành phần được cho phép khuyết thuộc tính kiểm tra. Nếu tồn tại, kiểu thay thế này sẽ là kiểu mặc định. Nếu không có xs:alternative được đưa ra định nghĩa kiểu mặc định là cái mà được mô tả cho thành phần.

Giá trị của thuộc tính type trên xs:alternative tương ứng với thuộc tính định nghĩa kiểu của thành phần lược đồ kiểu thay thế. Nếu biểu thức XPath trên thuộc tính test được đánh giá là đúng, thì type được chọn như một sự thay thế cho kiểu được khai báo trên thành phần. Kiểu type được đưa ra phải được thừa hưởng từ kiểu được mô tả hoặc một định nghĩa kiểu đơn được gọi là xs:error (cái mà không có các thể hiện hiệu lực). Kiểu xs:error có thể được sử dụng để làm cho thành phần trở thành có hiệu lực nếu chúng đáp ứng điều kiện cho kiểu thay thế.

Nếu một mô tả thành phần có kiểu thay thế, chúng được đánh giá nhằm mục đích rằng chúng được đưa ra trong lược đồ. Kiểu thay thế đầu tiên mà có biểu thức XPath được đánh giá là đúng là kiểu mà sẽ được chọn. Nếu không có biểu thức XPath nào trả lại giá trị đúng thì kiểu mặc định sẽ được chọn như là type cho thành phần.

Bây giờ, chúng ta đã mô tả cơ chế làm việc của các kiểu thay thế, hãy xem một ví dụ (Ví dụ 17) về cách bạn có thể sử dụng nó để viết một lược đồ cho Atom. Như đề cập ở trong phần trước, các thành phần chứa cấu trúc nguyên bản có thể có một thuộc tính type chỉ ra nội dung được phép cho thành phần. Đoạn mã nhỏ dưới đây chỉ ra cách để viết một mô tả cho một thành phần title trong Atom.

<xs:element name="title" type="xs:anyType">
  <xs:alternative test="@type='text'" type="xs:string"/>
  <xs:alternative test="@type='html'" type="htmlContentType"/>
  <xs:alternative test="@type='xhtml'" type="xhtmlContentType"/>
  <xs:alternative test="@type" type="xs:error"/>
  <xs:alternative type="xs:string"/>
</xs:element>

Mô tả thành phần cho title có một kiểu cơ sở là xs:anyType và đưa ra năm kiểu thay thế. Các kiểu thay thế được đánh giá theo thứ tự cho đến khi một biểu thức XPath trả lại giá trị đúng (hoặc, nếu không có biểu thức đúng, kiểu mặc định sẽ được chọn). Ba kiểu thay thế đầu tiên lựa chọn một kiểu dựa trên giá trị của thuộc tính type là text, html, or xhtml. Nếu thuộc tính type không có những giá trị đó, các biểu thức XPath cho ba kiểu thay thế đầu tiên sẽ trả lại giá trị sai. Kiểu thay thế thứ tư kiểm tra xem thuộc tính type có tồn tại hay không. Nếu trình xử lý lược đồ xử lý đến đây, giá trị của type (nếu nó tồn tại) không phải là giá trị mà Atom cho phép. Chúng ta gán kiểu cho sự thay thế này là xs:error để báo rằng nếu điều kiện này được thỏa mãn, thành phần là không có hiệu lực. Nếu không có biểu thức XPath nào trả lại giá trị đúng, kiểu mặc định (xs:string) được chọn.

Thể hiện của thành phần title, Ví dụ 18, minh họa các kiểu thay thế được lựa chọn như thế nào.

<!-- 1st type alternative selected: xs:string -->
<title type="text">My News</title>

<!-- 3rd type alternative selected: xhtmlContentType -->
<title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">My
 <xhtml:em>News</xhtml:em>!</title>

<!-- default type alternative selected: xs:string -->
<title>My News</title>

<!-- 4th type alternative selected: xs:error. Invalid. -->
<title type="unknown">Oops! Error.</title>

Kết luận

Trong bài này, chúng tôi đã đưa ra một cái nhìn tổng quan về hỗ trợ ràng buộc đồng thời trong lược đồ XML 1.1, nhấn mạnh sự bổ trợ của các xác nhận và kiểu thay thế tới giới hạn sự tồn tại và giá trị của các thành phần và thuộc tính. Trong Phần 3 của loạt bài này, chúng ta sẽ khám phá sự hỗ trợ ký tự thay thế và cách nó cho phép bạn cải tiến lược đồ XML của bạn.

Tài nguyên

Học tập

• XML Schema 1.1, Part 1: An introduction to XML Schema 1.1: An overview of the key improvements over XML Schema 1.0 and an in- depth look at datatypes (Neil Delima, Sandy Gao, Michael Glavassevich, Khaled Noaman; deveoperWorks; Tháng 12 2008): Bắt đầu tìm hiểu với cái nhìn tổng quan về các cái tiến chủ chốt trên lược đồ XML 1.0 và chi tiết về kiểu dữ liệu.
  
  
• XML 1.0 specification: Tìm hiểu về XML và cách nó cho phép SGML chung được phục vụ, nhận và xử lý trên web.
  
  
• XML Schema Part 1: Structures Second Edition: Tìm hiểu về ngôn ngữ lược đồ XML W3C và cách nó mô tả cấu trúc và các ràng buộc nội dung của tài liệu XML 1.0, bao gồm những cái mà khai thác chức năng miền không gian tên của XML. Đặc tả này phục thuộc vào bài XML Schema Part 2: Datatypes.
  
  
• XML Schema Part 2: Datatypes Second Edition: Tìm thông tin về các kiểu dữ liệu được sử dụng trong ngôn ngữ lược đồ XML W3C.
  
  
• W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures: Xem xét đặc tả mới nhất của ngôn ngữ lược đồ XML W3C.
  
  
• W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes: Tìm thêm thông tin về các kiểu dữ kiệu mới được thêm vào ngôn ngữ lược đồ XML W3C.
  
  
• XQuery 1.0: Tìm hiểu thêm về ngôn ngữ truy vấn XML sử dụng cấu trúc của XML để biểu diễn các truy vấn trên tất cả các loại dữ liệu.
  
  
• XML Path Language 2.0: Tìm hiểu thêm về ngôn ngữ XPath.
  
  
• Service Modeling Language (SML): Tìm hiểu thêm về cách mô hình hóa các hệ thống và dịch vụ phức hợp.
  
  
• XSL Transformations (XSLT) Version 2.0: Tổng quát về đặc tả mà định nghĩa cú pháp và ngữ nghĩa của ngôn ngữ XSLT 2.0.
  
  
• XQuery 1.0 and XPath 2.0 Data Model (XDM): Tìm hiểu về đặc tả W3C là mô hình dữ liệu của các ngôn ngữ XPath 2.0, XSLT 2.0, và XQuery.
  
  
• Atom Syndication Format: Tìm hiểu thêm về một định dạng tổ chức dữ liệu thông tin (metadata) và nội dung web dựa trên XML.
  
  
• Schematron: Xem xét ngôn ngữ này cho việc tạo ra các xác nhận về sự có mặt hoặc vắng mặt của các mẫu trong các tài liệu XML.
  
  
• RELAX NG: Khám phá một ngôn ngữ lược đồ cho XML.
  
  
• IBM XML certification: Cách mà bạn có thể có chứng chỉ của IBM về XML và các công nghệ liên quan.
  
  
• XML technical library: Xem developerWorks XML Zone để biết thêm các bài viết và mẹo, bài hướng dẫn, các tiêu chuẩn và sách của IBM.
  
  
• developerWorks technical events and webcasts: Cập nhật thông tin công nghệ của bạn ở đây.
  
  
• technology bookstore: Tìm sách về XML và công nghệ liên quan ở đây.
  
  
• developerWorks podcasts: Nghe trực tuyến các bài thảo luận và phỏng vấn hấp dẫn cho các nhà phát triển phần mềm.
  
  

Lấy sản phẩm và công nghệ

• The XML Parser for Java (Xerces2-J): Dùng thử trình phân tích này của Apache.
  
  
• IBM trial software for product evaluation: Xây dựng dự án tiếp theo của bạn với phần mềm dùng thử từ developerWorks, bao gồm các công cụ phát triển ứng dụng và sản phẩm phần mềm trung gian từ DB2®, Lotus®, Rational®, Tivoli®, và WebSphere®.
  
  

Thảo luận

• XML zone discussion forums: Tham gia các thảo luận liên quan đến XML.
  
  
• developerWorks XML zone: Share your thoughts: Chia sẻ suy nghĩ và góp ý của bạn sau khi đọc bài này. Các góp ý của bạn luôn được hoan nghênh.
  
  
• developerWorks blogs: Xem các nhật ký trực tuyến và tham gia cộng đồng developerWorks.
  
  

Đôi nét về các tác giả

Chấm điểm bài này

Bình luận

Về đầu trang

Mục lục

• Giới thiệu
• Lược sử
• Sự xác nhận (Assertions)
• Các kiểu dữ liệu thay thế (Type alternatives)
• Kết luận
• Tài nguyên
• Đôi nét về các tác giả
• Bình luận