Lược đồ XML 1.1, Phần 1: Lời giới thiệu đối với Lược đồ XML 1.1

Tổng quát về những tiến bộ đối với Lược đồ XML 1.0 và xem xét cụ thể đối với các kiểu dữ liệu

Do có nhiều ứng dụng và tính đa dạng của Lược đồ XML, nên người sử dụng đòi hỏi cần phải có các cải tiến và ứng dụng mới. Nhóm xây dựng Lược đồ XML W3C đã phát triển Lược đồ XML 1.1 nhằm giải quyết những đòi hỏi mới nảy sinh nói trên và kể cả những khiếm khuyết của Lược đồ XML 1.0. Trong phần đầu tiên của của loạt bài viết nhiều phần này các tác giả Neil Delima, Sandy Gao, Michael Glavassevich, và Khaled Noaman đã giới thiệu Lược đồ XML 1.1 với cái nhìn tổng quát đối với các đặc tính mới được phát triển nhằm đáp ứng với các tiêu chuẩn mới phát sinh và xem xét cụ thể đối với các nội dung bổ sung mới và các thay đổi đối với phần các dữ liệu của đặc tả này.

Neil Delima, Phát triển phần mềm, IBM

Neil Delima là nhân viên phát triển phần mềm của IBM tại phòng thí nghiệm Toronto. Là một thành viên của nhóm phát triển trình phân tích XML Parser, Neil đã làm việc với nhiệm vụ phát triển và kiểm tra công nghệ XML trong hơn 7 năm qua. Neil là thành viên của hội đồng kiểm duyệt dự án trình phân tích Apache’s Xerces – Java Parser và góp phần xây dựng các bộ kiểm tra cho W3C DOM và XML 1.1



Sandy Gao, Phát triển phần mềm, IBM

Sandy (Shudi) Gao là nhân viên phát triển phần mềm của IBM tại Toronto. Sandy đã là thành viên của hội đồng kiểm duyệt dự án trình phân tích Apache’s Xerces – Java Parser từ năm 2001 và là người đóng góp chủ chốt tới hỗ trợ lược đồ XML. Sandy đại diện IBM tham gia nhóm làm việc phát triển lược đồ XML của W3C từ năm 2003. Sandy đóng góp chính cho sự phát triển lược đồ XML 1.1 và trở thành chủ biên của đặc tả trong năm 2006. Sandy cũng đại diện IBM trong nhóm W3C SML Working Group



Michael Glavassevich, Phát triển phần mềm, IBM

Michael Glavassevich thành viên của nhóm XML Parser Development (phát triển trình phân tích XML) tại phòng thí nghiệm của IBM Toronto và là một trong những người có đóng góp to lớn đối dự án Apache Xerces2 trong 5 năm vừa qua, ngoài ra anh còn tham gia xây dựng Lược đồ XML, XInclude, JAXP 1.3/1.4 và DOM Level 3. Michael cũng là đại diện của của IBM trong nhóm chuyên gia JAXP đã xây dựng JAXP 1.4



Khaled Noaman, Phát triển phần mềm, IBM

Khaled Noaman là thành viên của nhóm phát triển trình phân tích XML Parser của phòng thí nghiệm IBM tại Toronto và trong vòng hơn 5 năm đã tham gia xây dựng Apache Xerces-C++ parser và nhiều năm qua đã triển khai nhiều nội dung của trình phân tích kể cả hỗ trợ đối với các cấu trúc lược đồ XML



20 05 2009

Giới thiệu

Các bài viết khác trong loạt bài viết này

Từ khi Ký tự đại diện Lược đồ XML 1.0 trở thành một khuyến cáo của W3C trong năm 2001, nhóm phát triển đã thảo luận về các lợi ích và các khiếm khuyết của loại ngôn ngữ này. Nhóm xây dựng Lược đồ XML W3C đã tiếp tục nghiên cứu xây dựng Ký tự đại diện ngôn ngữ tiếp theo. Năm 2005, với việc chuẩn này đã được áp dụng rộng rãi trong lĩnh vực này và được lồng ghép vào nhiều chuẩn khác như XSLT, XQuery và WSDL, W3C tổ chức một hội thảo nhằm phản hồi những bài học kinh nghiệm của người sử dụng và thu thập các phản hồi nhằm giúp cho việc phát triển ngôn ngữ này. Hội thảo này cùng với các yêu cầu đặt ra từ phía người sử dụng trong ngành đã giúp cho nhóm xây dựng Lược đồ XML hình thành được phạm vi của Ký tự đại diện chuẩn 1.1.

Các từ viết tắt hay dùng

  • W3C: World Wide Web Consortium
  • WSDL: Web Services Description Language
  • XML: Extensible Markup Language
  • XSLT: Extensible Stylesheet Language Transformations

Trong phần này chúng ta bắt đầu bằng việc xem xét một số đặc điểm mới của Lược đồ XML 1.1 và sau đó đi sâu vào những cải tiến cho kiểu dự liệu của bản đặc tả này. Chuẩn này được biết đến với tên gọi Ngôn ngữ xác định Lược đồ XML hay viết tắt là XSD. Chúng tôi dùng từ viết tắt này cho bài báo này cũng như trong toàn bộ loạt bài viết. Đôi khi, nêu rõ nghĩa thì Lược đồ XML hay Lược đồ được dùng để nói đến ngôn ngữ này.

Độc giả nên nhớ bài viết này được viết khi Lược đồ XML 1.1 vẫn đang trong quá trình xây dựng. Một vài chi tiết có thể sẽ thay đổi trước khi Lược đồ XML 1.1 trở thành Khuyến nghị W3C.

Những khó khăn của Lược đồ XML 1.0

Các tác giả của Lược đồ thường gặp một số những khó khăn nhất định. Bạn có thể lẩn tránh một số vấn đề khó khăn và tạo ra các thiết kế lược đồ phản trực giác, hoặc bạn có thể xử lý một số vấn đề khó khăn khác bằng mã hóa trong các ngôn ngữ lập trình.

Phần này sẽ xem xét những vấn đề dễ phát sinh nhất và thảo luận xem làm thế nào Lược đồ XML 1.1 có thể xử lý chúng. Chi tiết về thảo luận sẽ có ở các phần tiếp sau của bài báo này

Giới hạn của mô hình nội dung

Các kiểu phức tạp có thể có nhiều loại nội dung khác nhau. Những kiểu có phần tử (element) con có thể sẽ phải có một trong <xs:sequence>, <xs:choice>, hoặc <xs:all> như các mô hình nội dung của chúng. Khi một kiểu phức tạp dẫn xuất bởi giới hạn của một kiểu khác thì cả hai mô hình nội dung đều phải thỏa mãn một số ràng buộc nhất định. Những ràng buộc này phải thật cụ thể để đảm bảo cái đã được cho phép bởi kiểu ràng buộc cũng được cho phép đối với các kiểu cơ sở

Trong Lược đồ XML 1.0, những ràng buộc này được cụ thể hóa nhờ bảng 25-case và các mô hình nội dung đều có vẻ giống nhau để thỏa mãn các ràng buộc này, điều này dẫn tới nẩy sinh các vấn đề sau:

  • Các luật chặt chẽ trong 25 cases bỏ đi một số dẫn xuất hợp lệ.
  • Luật cho phép một vài dẫn xuất không hợp lệ (đó là, các ràng buộc cho phép nhiều hơn cơ sở).

Ví dụ, trong ví dụ 1 kiểu derived loại bỏ phần tử tùy chọn tns:a từ kiểu based. Đây rõ ràng là một giới hạn hợp lệ, nhưng lại không hợp lệ trong Lược đồ XML 1.0

Ví dụ 1. Một kiểu derived loại bỏ phần tử tùy chọn từ kiểu cơ sở
<complexType name="base">
  <complexContent>
    <sequence>
      <element ref="tns:a" minOccurs="0" maxOccurs="1"/>
      <choice minOccurs="0" maxOccurs="unbounded">
        <element ref="tns:b"/>
        <element ref="tns:c"/>
      </choice>
    </sequence>
  </complexContent>
</complexType>

<complexType name="derived">
  <complexContent>
    <restriction base="tns:base">
      <sequence>
        <choice minOccurs="0" maxOccurs="unbounded">
          <element ref="tns:b"/>
          <element ref="tns:c"/>
        </choice>
      </sequence>
    </restriction>
  </complexContent>
</complexType>

Trong Lược đồ XML 1.1, luật của 25-case được loại bỏ và thay bằng một khái niệm giản đơn nhằm phản ánh được mục tiêu “cái được cho phép bởi giới hạn thì cũng được cho phép bởi cơ sở". Ví dụ trên trở thành hợp lệ trong Lược đồ XML 1.1

Đồng ràng buộc

Các tác giả Lược đồ thường muốn áp dụng các luật liên quan đến cho nhiều phần tử hay thuộc tính (attribute). Ví dụ "min cần bé hơn hoặc bằng với max", hoặc "số lượng các phần tử con cần phải phù hợp với đặc tính size. Các luật giống như vậy thường được gọi các đồng xuất hiện ràng buộc hoặc đơn giản là các đồng ràng buộc.

Lược đồ XML 1.0 không cung cấp phương tiện để hỗ trợ cho các đồng ràng buộc. Người dùng đôi khi phải viết JAVA™ hoặc mã C để kiểm tra chúng sau khi tài liệu XML được tải về bộ nhớ. Điều này ảnh hưởng đến tính bền vững và làm lược đồ trở nên yếu đi. Một số người sử dụng tìm kiếm sự giúp đỡ từ các ngôn ngữ kiểm chuẩn XML (XML validation) khác như Schematron và Relax NG (xem Tài nguyên) cho sự hỗ trợ đồng ràng buộc, mà lại làm phức tạp kiến trúc dựa trên XSD của chúng.

Lược đồ XML 1.1 hỗ trợ các đồng ràng buộc một cách tự nhiên. Cái mới được đưa ra là <xs:assert> nhân tố có thể bao gồm các ràng buộc được xác định cụ thể trong các biểu thức trong XPath 2.0 (xem Tài nguyên). Xem Ví dụ 2:

Ví dụ 2. Các đồng ràng buộc Lược đồ XML 1.1
<xs:complexType name="intRange">
  <xs:attribute name="min" type="xs:int"/>
  <xs:attribute name="max" type="xs:int"/>
  <xs:assert test="@min <= @max"/>
</xs:complexType>

Phát triển lược đồ (Schema)

Mọi người đều thấy cần phải phát triển lược đồ của mình, thêm các mở rộng đối với các thông tin mới. Ký tự đại diện (wildcard) là công cụ hữu hiệu được thiết kế cho mục đích này. Nó có thể dùng cho các Ký tự đại diện lược đồ cũ để cho phép các điểm mở rộng và trong các Ký tự đại diện sau này, các phần tử cụ thể có thể được đưa ra thay cho Ký tự đại diện này. Nhưng những Ký tự đại diện lại có các vấn đề đáng tiếc như sau:

  • Chính luật gây tranh cãi Unique Particle Attribution (UPA) gây khó khăn khi sử dụng các Ký tự đại diện tùy chọn
  • Các Ký tự đại diện không được đủ mạnh để miêu tả “mọi phần tử ngoại trừ những phần tử dưới đây"
  • Việc lặp đi lặp lại cùng một Ký tự đại diện đối cho mỗi kiểu phức tạp để làm cho toàn bộ lược đồ có tính mở rộng sẽ gây tẻ nhạt.

Lược đồ XML 1.1 làm cho phát triển lược đồ dễ dàng hơn. Ngoài ra các Ký tự đại diện được cải tiến mạnh mẽ. Sẽ không còn vi phạm lỗi UPA khi mâu thuẫn với các phần tử được xác định cụ thể rõ ràng và chúng có thể loại trừ được một danh sách các không gian tên (namespaces) hay một danh sách các tên, chúng thậm chí có thể để tự mặc định. Điều này sẽ dễ dàng hơn bao giờ hết để viết các lược đồ mở rộng.

Ví dụ, để trình bày một mô hình nội dung đối với "một và chỉ một phần tử gọi là userName và một số phần tử khác, trước và sau userName", bạn xác định mô hình nội dung như trong Ví dụ 3.

Ví dụ 3. Mô hình nội dung trong Lược đồ XML 1.0
<xs:sequence>
  <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
  <xs:element ref="tns:userName"/>
  <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/>
</xs:sequence>

Nhưng lại không hợp lệ trong Lược đồ XML 1.0. Khi phần tử có tên userName lại bắt gặp, điều này không chắc chắn liệu có phù hợp với Ký tự đại diện <xs:any> hoặc lời gọi phần tử <xs:element> để giải quyết vấn đề này, một số người chèn phần tử ngăn cách giữa các phần tử và Ký tự đại diện. Việc này có hiệu quả nhưng làm cho cả lược đồ và các tài liệu XML rất xấu. Một vấn đề khác là Ký tự đại diện này cũng cho phép userName, vì thế luật "một và chỉ một " không thể áp dụng.

Trong Lược đồ XML 1.1, lược đồ chia nhỏ trong ví dụ 3 trở nên hợp lệ do bởi các Ký tự đại diện đã được làm yếu đi, có nghĩa là khi một phần tử đã phù hợp với khai báo phần tử hoặc là một Ký tự đại diện thì khai báo phần tử luôn được ưu tiên trước. Điều này tránh được tồn tại của UPA. Với sự giúp đỡ của của Ký tự đại diện phủ định, bạn luôn có thể biểu diễn luật “một và chỉ một userName và bất kỳ điều nào khác" trong ví dụ 4.

Ví dụ 4. Mô hình nội dung trong Lược đồ XML 1.1
<xs:sequence>
  <xs:any minOccurs="0" maxOccurs="unbounded"
          processContents="skip" notQName="tns:userName"/>
  <xs:element ref="tns:userName"/>
  <xs:any minOccurs="0" maxOccurs="unbounded"
          processContents="skip" notQName="tns:userName"/>
</xs:sequence>

Các kiểu dữ liệu Lược đồ XML

Nội dung bản đặc tả của Lược đồ XML gồm 2 phần: Cấu trúc và kiểu dữ liệu (xem Tài nguyên). Trong phần này, chúng ta sẽ đề cập đến các thay đổi trong phần kiểu dữ liệu của bản đặc tả là một phần của Lược đồ XML 1.1 đã đưa ra. Trong các bài viết sau, chúng ta sẽ đi vào cụ thể các thay đổi với phần Cấu trúc.

Phù hợp với các loại mô hình dữ liệu XQuery 1.0 và XPath 2.0

Kiểu hệ thống sử dụng bởi W3C XQuery 1.0, XPath 2.0, XSLT 2.0 và XQuery 1.0 và XPath 2.0 Data Model Recommendations (xem Tài nguyên) là phần mở rộng trong Khuyến nghị Lược đồ XML W3C 1.0. Ngoài các kiểu dữ liệu gốc đã có sẵn Lược đồ XML 1.0, những bản đặc tả này còn xác định 5 kiểu dữ liệu bổ sung thêm trong miền tên Lược đồ XML 1.0, gọi là: anyAtomicType, untyped, untypedAtomic, dayTimeDuration yearMonthDuration. Để phù hợp với kiểu hệ thống của Lược đồ XML và các đặc tả này, đặc tả kiểu dữ liệu của Lược đồ XML 1.1 đưa ra 3 kiểu dữ liệu, gọi là: anyAtomicType, dayTimeDuration, và yearMonthDuration .

anyAtomicType

anyAtomicType là kiểu dữ liệu có sẵn đặc biệt của Lược đồ XML 1.1 bắt nguồn bởi ràng buộc từ anySimpleType. Từ khi anyAtomicType là cơ sở cho các kiểu dữ liệu gốc, giá trị và không gian ngôn ngữ (lexical space) của anyAtomicType là sự hợp nhất của giá trị và không gian ngôn ngữ của tất cả các kiểu dữ liệu gốc. Để giải thích rõ hơn, hãy xem Lược đồ XML ở ví dụ 5 và tài liệu hợp lệ của XML (ví dụ 6) dưới đây. Trong ví dụ này, phần tử kiểu anyAtomicType có thể hàm chứa một chuỗi hoặc số nguyên như một giá trị hợp lệ. Có thể áp dụng cho kiểu cụ thể được xuất dẫn từ anyAtomicType mà sử dụng xsi:type. Cần chỉ ra rằng anyAtomicType không xác định bất cứ phần tử ràng buộc nào do đó bạn không thể dùng nó như là kiểu cơ sở của kiểu giản đơn do người dùng xác định (user-defined simple type).

Ví dụ 5. Ví dụ Lược đồ XML cho anyAtomicType
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="test" xmlns:pfx="test">
   <element name="root">
      <complexType>
         <sequence>
            <element name="elanyAtomicType" type="anyAtomicType"
                     maxOccurs="unbounded"/>
         </sequence>
      </complexType>
   </element>
</schema>
Ví dụ 6. Ví dụ về tài liệu XML cho anyAtomicType
<pfx:root xmlns:pfx="test" xmlns:xs="http://www.w3.org/2001/XMLSchema"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <elanyAtomicType>Test</elanyAtomicType>
   <elanyAtomicType>12345</elanyAtomicType>
   <elanyAtomicType xsi:type="xs:string">Test</elanyAtomicType>
   <elanyAtomicType xsi:type="xs:integer">12345</elanyAtomicType>
</pfx:root>

yearMonthDuration

Kiểu dữ liệu duration (khoảng thời gian) trình bày trong XML Schema 1.0 Datatypes Recommendation (xem Tài nguyên) là một kiểu được xếp thứ tự một phần nào đó và đại diện cho một giai đoạn thời gian, ví dụ các giá trị duration P30D và P1M là không thể so sánh được do một tháng thì có thể bao gồm bất kỳ từ 28 đến 31 ngày. Để giúp cho các khoảng thời gian có thể so sánh được, Lược đồ XML 1.1 đưa ra hai kiểu dữ liệu thứ tự hoàn toàn mới, gọi là yearMonthDuration dayTimeDuration bắt nguồn bởi ràng buộc từ duration.

Trong Lược đồ XML 1.1, kiểu dữ liệu yearMonthDuration được bắt nguồn từ duration bằng cách giới hạn đối với trình bày ngôn từ để khống chế chỉ hai thành phần năm và tháng. Bạn có thể trình bày bằng một biểu thức thông thường: -?P[0-9]+(Y([0-9]+M)?|M) Giá trị của thành phần năm và tháng cho phép sử dụng một số nguyên không dấu (unsigned integer). Ký hiệu dấu trừ tùy chọn sẽ hiểu là một yearMonthDuration số âm. Không gian giá trị của kiểu dữ liệu duration bao gồm một số nguyên các tháng và một số thập phân các giây. Không gian giá trị của kiểu dữ liệu yearMonthDuration là giới hạn của không gian giá trị của kiểu dữ liệu duration với giá trị các giây là không (0).

Một số dương yearMonthDuration của một năm và sáu tháng có thể biểu đạt về từ ngữ là P1Y6M hoặc P18M. Giá trị của yearMonthDuration là 18 tháng. Các ví dụ của các giá trị yearMonthDuration hợp lệ bao gồm P1Y2M, P12Y, -P20M, trong khi các trình bày dưới đây là không hợp lệ P-1Y , P1Y-1MP1YM. Kiểu dữ liệu yearMonthDuration được xếp thứ tự toàn bộ, đối với bất kỳ 2 giá trị yearMonthDuration D1 D2 mối quan hệ thứ tự giữa D1 D2 có thể được thiết lập, có nghĩa hoặc là D1 > D2 hoặc D1 < D2.

Kiểu dữ liệu người sử dụng xác định có thể dẫn xuất từ ràng buộc từ yearMonthDuration, bằng cách xác định các phần tử ràng buộc cho phép bởi duration. Từ khi yearMonthDuration dẫn xuất bởi giới hạn từ duration là phần tử cơ bản, có thứ tự và một phần cũng không bị thay đổi bởi dẫn xuất. Tuy nhiên, yearMonthDuration trên thực tế được sắp xếp hoàn toàn.

dayTimeDuration

Tương tự đối với yearMonthDuration, kiểu dữ liệu dayTimeDuration dẫn xuất từ duration bằng cách giới hạn cách biểu diễn ngôn từ để chỉ bao gồm các thành phần ngày và thời gian (giờ, phút, giây) từ kiểu dữ liệu duration. Điều này có thể trình bày bằng các khoảng thời gian phù hợp với các biểu thức thông thường [^YM]*[DT].*. Giá trị của các thành phần ngày, giờ, phút là bị giới hạn, nhưng vẫn cho một xs:integer không dấu tùy ý. Tương tự, các giá trị của thành phần giây cho phép một xs:decimal không dấu tùy ý. Dấu âm tự chọn phản ánh một số âm dayTimeDuration. Không gian giá trị của kiểu dữ liệu dayTimeDuration là ràng buộc về miền giá trị của kiểu dữ liệu duration với giá trị thuộc tính các tháng là 0 và giá trị các giây là phân số.

Một số dương dayTimeDuration của một ngày, hai giờ, ba phút và 4,5 giây có thể diễn đạt dưới dạng ngôn từ là P1DT2H3M4.5S. Giá trị của yearMonthDuration là 93784.5 (1*24*60*60+2*60*60+3*60+4.5) phân số cho các giây. Chú ý rằng số lượng của ngày, giờ, phút và giây là 0, có thể bỏ qua trình bày dưới dạng ngôn từ miễn là nếu có ít nhất một trong chúng được thể hiện. Nếu như dayTimeDuration chỉ bao gồm các ngày, thì thiết kế cho T phải bỏ đi. Thêm một số ví dụ dayTimeDuration hợp lệ bao gồm P1D, PT25H, P22DT2H, PT1H99M5, 5S, -PT20M, -PT60.60S và một số ví dụ dayTimeDuration không hợp lệ là P-5D, P1D1M1H1S, PDT1M, P5HP1DT. Giống như yearMonthDuration, kiểu dữ liệu dayTimeDuration hoàn toàn có thứ tự.

Kiểu dữ liệu dẫn xuất từ ràng buộc từ dayTimeDuration có thể xác định các phần tử ràng buộc giống nhau ví dụ như kiểu dữ liệu duration. Chú ý rằng giá trị của vùng trắng(whitespace) các phần tử cho yearMonthDuration dayTimeDuration được gắn với collapse và không thể thay đổi.

Ví dụ 7 miêu tả một phần hợp lệ của Lược đồ XML 1.1 sử dụng kiểu dữ liệu yearMonthDuration dayTimeDuration .

Ví dụ 7. Ví dụ Lược đồ XML cho yearMonthDuration và dayTimeDuration
<schema xmlns="http://www.w3.org/2001/XMLSchema"
        targetNamespace="test" xmlns:pfx="test">
   <simpleType name="ymdBase">
      <restriction  base="yearMonthDuration">
         <minInclusive value="P1Y6M"/>
      </restriction>
   </simpleType>
   <simpleType name="ymdDerived">
      <restriction  base="ymdBase">
         <minInclusive value="P19M"/>
      </restriction>
   </simpleType>

   <simpleType name="dtdBase">
      <restriction  base="dayTimeDuration">
         <maxInclusive value="-P2DT2H"/>
      </restriction>
   </simpleType>
   <simpleType name="dtdDerived">
      <restriction  base="dtdBase">
         <maxInclusive value="-P51H"/>
      </restriction>
   </simpleType>

   <element name="root">
      <complexType>
         <sequence>
            <element name="elYearMonthDuration" type="ymdDerived"/>
            <element name="elDayTimeDuration" type="dtdDerived"/>
         </sequence>
      </complexType>
   </element>
</schema>

Ví dụ 7 miêu tả một phần hợp lệ của Lược đồ XML 1.1 sử dụng các kiểu dữ liệu yearMonthDuration dayTimeDuration. Kiểu đơn giản ymdDerived giới hạn kiểu cơ sở ymdBase, nó tiếp theo lại giới hạn kiểu dữ liệu dựng sẵn Lược đồ XML yearMonthDuration mà sử dụng phần tử minInclusive. Vì yearMonthDuration là được đặt thứ tự toàn bộ, giá trị P19M của kiểu dẫn xuất ymdDerived lớn hơn nhiều so với giá trị của P1Y6M kiểu cơ sở ymdBase tạo nên một ràng buộc có hiệu lực. Tương tự, kiểu đơn giản maxDerived giới hạn kiểu cơ sở dtdBase, nó đến lượt lại giới hạn kiểu dữ liệu dựng sẵn Lược đồ XML dayTimeDuration mà sử dụng phần tử maxInclusive. Trong trường hợp này, khoảng giá trị âm của -P51H của kiểu dẫn xuất maxDerived nhỏ hơn so với của kiểu cơ sở -P2DT2H. Phần tử, gốc chứa phần tử con elyearMonthDuration eldayTimeDuration của các kiểu ymdDerived maxDerived riêng biệt.

precisionDecimal

precisionDecimal là kiểu mới trong Lược đồ XML 1.1 nhằm hỗ trợ cho kiểu dấu phẩy động thập phân IEEE-754 mới. Nó khác với thập phân trong đó các số thập phân chính xác không chỉ gồm các giá trị về số mà còn giữ lại được sự chính xác số học. precisionDecimal cũng bao gồm các giá trị đối với vô cực dương (+INF) và vô cực âm (-INF) và không đối với số (NaN). Cũng có sự khác biệt giữa dương không (+0) và âm không (-0).

Miền ngôn từ của precisionDecimal là một bộ của tất cả các số thập phân (có hay không có dấu thập phân), các số biểu diễn dưới dạng khoa học (số mũ), và chuỗi ký tự 'INF', '+INF', '-INF và 'NaN'.

Kiểu dữ liệu do người sử dụng xác định dẫn xuất từ ràng buộc của precisionDecimal có thể xác định các phần tử ràng buộc giống nhau như của decimal. Ngoài ra, hai phần tử ràng buộc mới, maxScaleminScale được đưa ra để cho phép các kiểu dẫn xuất nhằm giới hạn lại các miền giá trị của precisionDecimal. Một maxScale đặt ra một giá trị giới hạn trên trong khi minScale đặt ra một giá trị giới hạn dưới về chính xác số học của các giá trị precisionDecimal.

Trong ví dụ 8 chúng ta xác định kiểu price mới mà chấp nhận giá trị giữa -999,999.99999,999.99.

Ví dụ 8. Ví dụ của một bộ phận của Lược đồ XML sử dụng precisionDecimal
<xs:simpleType name='price'>
  <xs:restriction base='xs:precisionDecimal'>
    <xs:totalDigits value='8'/>
    <xs:minScale value='2'/>
    <xs:maxScale value='2'/>
  </xs:restriction>
</xs:simpleType>

Nên ghi nhớ khi sử dụng NaN rằng không thể so sánh với bất kỳ giá trị nào khác kể cả chính nó, vì vậy nếu sử dụng NaN đối với bất kỳ các phần tử giới hạn nào (minInclusive, maxInclusive, minExclusive hoặc maxExclusive), kết quả là sẽ thu được một kiểu dữ liệu có miền giá trị rỗng.

Tương tự, kể cả NaN trong một bảng liệt kê sẽ không chấp nhận các giá trị NaN . Nếu muốn có NaN là một phần của miền giá trị, xác định kiểu tổng hợp mà chỉ có kiểu dữ liệu NaN (bằng cách xác định một phần tử mẫu với giá trị của " NaN ").

Vùng thời gian (Timezone) đối với Vùng thời gian offset

Các kiểu dữ liệu có liên quan đến date, time, và datemonth được xác định trong đặc tả của Lược đồ XML 1.0 bao gồm vùng thời gian tùy chọn dưới dạng (('+' | '-') hh ':' mm) | 'Z'. Khi một giá trị vùng thời gian được thêm vào một dateTime của Universal Coordinated Time (UTC), nó sẽ tạo ra date và time trong vùng thời gian đó.

Mặc dù đặc tả của Lược đồ XML 1.0 có một vùng thời gian offset, nhưng nó sử dụng thuật ngữ vùng thời gian để miêu tả nó, điều này gây hiểu nhầm giữa vùng thời gian và vùng thời gian offset đây là hai khái niệm khác nhau. Một vùng thời gian xác định trong một vùng hoặc một khu vực cụ thể (ví dụ thời gian ở Thái bình Dương, Pacific Time) trong khi vùng thời gian offset là sự khác biệt về thời gian về giờ và phút giữa UTC và một vùng thời gian nhất định nào đó (ví dụ, 11:00-05:00). Đặc tả Lược đồ XML 1.1 đã giới hạn vấn đề này và đã phân biệt rõ giữa vùng thời gian và vùng thời gian offset.

Những giây nhảy (leap)

Một giây nhảy là một giây thêm vào ngày cuối cùng của tháng 3, tháng 6, 10 hoặc 12, có nghĩa rằng phút cuối cùng của ngày cuối của các tháng này có nhiều hơn 60 giây. Một giây nhảy được thêm vào nhằm giữ cho UTC trong vòng 0,9 giây của thời gian quan sát thiên văn.

Do kiểu dữ liệu gắn với date và time đã xác định trong đặc tả của Lược đồ XML 1.1 không hỗ trợ các giây nhảy, do đó chúng không thể được sử dụng để đại diện cho các giây cuối cùng trong UTC hoặc trong bất kỳ ngày này mà có giây nhảy bổ sung vào chúng. Một ví dụ về những ngày như vậy là 1972-06-30. Người sử dụng phải điều chỉnh thích hợp ở mức ứng dụng nhằm giải quyết tình trạng thời gian này nếu thấy cần thiết phải tuân theo các giây nhảy này.

Các kiểu đơn giản Implementation-defined và các phần tử

Đặc tả Lược đồ XML xác định một số các kiểu gốc như string, booleandouble, đó chính là bộ xử lý hiểu và cung cấp phương tiện thực hiện. Rất nhiều hệ thống cần nhiều kiểu hơn so với số lượng đã có sẵn trong đặc tả. Có thể đáp ứng một số yêu cầu này bằng cách dẫn xuất từ nhưng cái đang có sẵn, nhưng không thể từ các cái khác.

Các kiểu gốc Implementation-defined

Lược đồ XML 1.1 hiện nay có thể cho phép các phần thực hiện của các bộ xử lý Lược đồ XML xác định các kiểu gốc riêng của chúng. Tùy theo từng bộ xử lý Lược đồ XML quyết định xem có nhận biết các kiểu này hay không.

Phần thực hiện cần tuân theo các luật sau:

  • Sử dụng anyAtomicType là kiểu cơ sở
  • Quyết định phần tử ràng buộc nào sẽ sử dụng và với ý nghĩa như thế nào (CHÚ Ý: phải bao gồm cả phần tử vùng trắng).
  • Xác định cơ chế tham khảo kiểu mới với vùng tên mục tiêu khác biệt với http://www.w3.org/2001/XMLSchema (được điều khiển bởi W3C).
  • Xác định vùng ngôn từ, vùng giá trị, và bản đồ ngôn từ cho kiểu mới.
  • Xác định mức so sánh bình đẳng trong mối quan hệ.
  • Xác định các giá trị cho các phần tử cơ bản.

Như một phần thực hiện của bộ xử lý XML, chúng ta cần phải xác định kiểu dữ liệu date đặc biệt tuân theo mẫu ngày-tháng-năm nhưng sử dụng nhiều dấu ngăn cách khác nhau không chỉ là dấu gạch ngang (-). Để tuân theo những luật đã xác định ở trên, chúng ta sử dụng anyAtomicType đối với kiểu cơ sở, và chúng ta xác định một miền tên mới có thể gọi là "http://www.example.com/XMLSchema-primitiveTypes". Chúng ta muốn thời gian của chúng ta được thể hiện dưới dạng ngày, dấu cách, tháng, dấu cách, năm. Trong vùng ngôn từ cho kiểu dữ liệu date, những thể hiện cho ngày, tháng, năm sẽ có cùng cách biểu thị như các kiểu được xác định trong Lược đồ XML 1.1 và với cùng những luật. Chúng ta muốn dấu cách thể hiện là một trong ba giá trị dưới đây: dấu chấm (.), gạch ngang (-), gạch chéo (/).

Chúng ta cũng xác định các phần tử mà chúng ta sẽ hỗ trợ trong phần thực hiện của chúng ta. Các phần tử cơ bản có thể gồm các phần tử và giá trị dưới đây:

  • ordered: partial
  • bounded: false
  • cardinality: countably infinite
  • numeric: false

Theo các luật, chúng ta cần có một phần tử vùng trắng, chúng ta sẽ xác định nó với giá trị “collapsed” áp dụng cho date và tất cả các kiểu dữ liệu dẫn xuất. Với mỗi đặc tả của Lược đồ XML 1.1, chúng ta có thể xác định được các phần tử ràng buộc và các giá trị mà chúng ta đã chọn, ví dụ:

  • pattern
  • enumeration
  • maxInclusive
  • maxExclusive
  • minInclusive
  • minExclusive
  • assertions
  • dateSeparator (implementation-defined)

Sử dụng sự xác định này, "2008-11-01", "2008.11.01", và "2008/11/01" tất cả đều là biểu diễn ngôn từ hợp lệ của ngày tháng, chúng thể hiện cùng ngày “1/11/2008”.

Các phần tử Implementation-defined

Đặc tả Lược đồ XML xác định một tập các phần tử ràng buộc (như là minInclusive hoặc là maxLength) có thể áp dụng các kiểu đơn giản. Một phần tử ràng buộc là một cấu trúc để khống chế vùng giá trị của các kiểu đơn giản khi dẫn xuất. Bộ xử lý nhận thức lược đồ hiểu và hỗ trợ các phần tử ràng buộc.

Tương tự như các kiểu Implementation-defined, Lược đồ XML 1.1 cho phép các phần xử lý được xác định các phần tử ràng buộc riêng của chúng và tuỳ theo từng phần xử lý Lược đồ XML mà có hỗ trợ các phần tử này hay không.

Đây là một số luật phải tuân thủ:

  • Xác định thuộc tính của phần tử
  • Xác định cách thức hoạt động của phần tử
  • Xác định cơ chế để tham khảo với các phần tử mới với không gian tên hơn là http://www.w3.org/2001/XMLSchema (khi mà W3C quản lý không gian tên).
  • Xác định các kiểu dữ liệu gốc mà phần tử ràng buộc mới áp dụng.

Trong ví dụ 9 sẽ thấy một bộ thực hiện bộ xử lý XML có thể xác định phần tử dateSeparator mà ràng buộc phân cách trong vùng giá trị của implementation-defined date và tất cả kiểu dữ liệu dẫn xuất từ nó.

Ví dụ 9. Một ví dụ về phần tử implementation-defined
<dateSeparator
    fixed = boolean : false
    id  = ID
    value = '-' | '.' | '/'

    ...   >
  (optional element content here)
    ...
</dateSeparator>

Xác định phần tử có thể xác định các đặc tính khác với không gian tên không - lược đồ ngoài fixed, idvalue. Bất cứ kiểu dẫn xuất nào có thể giới hạn vùng giá trị của implementation-defined date bằng cách áp dụng phần tử dateSeparator.

Bây giờ chúng ta xem xét làm thế nào một người sử dụng có thể dùng kiểu dữ liệu và các phần tử của nó. Trong ví dụ 10 chúng ta xác định một kiểu mới specialDate sử dụng một phần tử mới để giới hạn sự hiện diện của date để chỉ chấp nhận các giá trị có dấu (/) ngăn cách.

Ví dụ 10. Một ví dụ về kiểu dẫn xuất dựa vào kiểu implementation-defined
<xs:simpleType name="specialDate">
  <xs:restriction base="xyz:date">
    <xyz:dateSeparator value="/" />
  <xs:restriction>
</xs:simpleType>

Bây giờ chỉ "2008/11/01" được cho phép bởi specialDate, và "2008-11-01" và "2008.11.01" thì không được.

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ề Lược đồ XML 1.1, vạch ra các vấn đề của Lược đồ XML 1.0 và giới thiệu sơ qua làm thế nào Lược đồ XML 1.1 giải quyết những vấn đề đó với một số ví dụ về giới hạn mô hình nội dung, đồng giới hạn và phát triển lược đồ qua các sử dụng của Ký tự đại diện. Chúng ta sau đó đã xem xét cụ thể các tiến bộ đối với phần kiểu dữ liệu của bản đặc tả bao gồm cả các kiểu dữ liệu mới và cho phép các kiểu gốc implementation-defined và các phần tử. Trong Phần 2 của loạt bài, chúng tôi sẽ xem xét kỹ hơn về đặc điểm các đồng ràng buộc mới, đặc biệt các xác nhận và cơ chế giao việc loại có điều kiện.

Tài nguyên

Học tập

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

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Nguồn mở
ArticleID=389850
ArticleTitle=Lược đồ XML 1.1, Phần 1: Lời giới thiệu đối với Lược đồ XML 1.1
publish-date=05202009