Khai báo Element – Tag và Attributes. Sử dụng DTD để kiểm tra tài liệu XML

Khai báo Element – Tag và Attributes. Sử dụng DTD để kiểm tra tài liệu XML được viết đúng theo đúng định dạng dùng để truy xuất và giao tiếp (validation).

Mục đích: Chủ đề của bài này giới thiệu về DTD – một phương pháp dùng để kiểm tra tài liệu XML viết đúng theo chuẩn giao tiếp và truy xuất giữa người gửi và người nhận. Nội dung đề cập đến sự cần thiết có để có DTD, cách viết và sử dụng DTD cho đúng để kiểm tra tài liệu xml. Nội dung bài này tập trung vào khai báo tag và thuộc tính trong tài liệu DTD để áp dụng cho tài liệu XML. Qua nội dung tổng quát của lý thuyết, chúng tôi sẽ thực hiện một số ví dụ liên quan nhằm hiểu rõ nội dung của lý thuyết đã đề ra.

Yêu cầu về kiến thức cơ bản cho các khái niệm về XML

• Nắm vững các khái niệm về XML và cách viết tài liệu XML well-formed (tham khảo lại bài Giới thiệu về XML – định nghĩa, cách viết XML đúng cú pháp (XML well-formed))

• Nắm vững khái niệm về ngôn ngữ lập trình Java, lập trình thao tác hướng đối tượng

• Đã viết và kiểm tra một tài liệu XML well-formed

Tổng quan DTD

• Sự cần thiết phải sử dụng DTD để validation tài liệu XML

  • XML hướng tới việc tổ chức dữ liệu theo dạng cấu trúc để chia sẻ, khai thác và trao đổi lẫn nhau giữa các ứng dụng, giữa người sử dụng và tổ chức (gọi tắt là ứng dụng)

  • Tuy nhiên, chính việc định nghĩa các tag một cách tùy ý theo người dùng dẫn đến việc người sử dụng xml có thể hiểu sai ngữ nghĩa trong việc truyền dữ liệu trong giao tiếp và truy xuất giữa các ứng dụng

  • Ngoài ra, trong quá trình tổ chức dữ liệu chúng ta cũng mong muốn kiểm tra xem dữ liệu chúng ta có đúng như kiểu mong muốn để giao tiếp giữa người gửi và người nhận. Hơn thế nữa, cũng giống như ngôn ngữ lập trình, chúng ta mong muốn một số giá trị trong tài liệu XML nên được khởi tạo sẵn giá trị để khi chúng ta quên gán trị thì giá trị được thiết lập mặc định, tránh trường hợp giá trị truy xuất không có và được ứng dụng gán cho giá trị null và gây nên lỗi không đáng có trong quá trình xử lý

  • Ngoài những yếu tố nêu trên, chúng ta cũng cần đảm bảo cấu trúc dữ liệu tổ chức phải đúng cấu trúc và định dạng format khi thực hiện trao đổi và giao tiếp giữa các ứng dụng, đảm bảo tính ổn định trong quá trình xử lý

  • Giống tương tự khái niệm quan hệ giữa các thực thể trong database và ràng buộc giữa các thành phần dữ liệu, thì tài liệu XML cũng cần đảm bảo các ràng buộc và mối quan hệ giữa các thành phần dữ liệu được tổ chức trong tài liệu để hạn chế sai sót khi chia sẻ dữ liệu

  • Tài liệu XML được validation nghĩa là tài liệu XML đã well-formed và tuân thủ đúng định dạng qui định trong giao tiếp và truy xuất

• Định nghĩa DTD

• Viết tắt của từ Document Type Definition

• Một cơ chế dùng để xác định hay định nghĩa tài liệu có bao nhiêu tag, bao nhiêu attributes, attribute của tag nào và mối quan hệ giữa các tag và định nghĩa các thành phần tương tự như macro hay biến hàng hay tham số truyền trong ngôn ngữ lặp trình (trong DTD và XML được gọi là entity) nhằm tăng tính hiệu quả trong việc sử dụng XML và đảm bảo đúng những điều đã được đề cập trong sự cần thiết phải có DTD

• DTD được viết sử dụng ngôn ngữ Extended Backus-Naur Form (EBNF), một ngôn ngữ xuất phát từ SGML và có cấu trúc không phải theo XML

• Hỗ trợ bộ XML Parser có hỗ trợ validation kiểm tra tính đúng đắn của tài liệu XML trước khi xử lý và truyền dữ liệu đến client

• Hỗ trợ người sử dụng tài liệu XML có kết hợp DTD thiết lập giá trị khởi tạo cho thuộc tính trong tài liệu XML

• Đảm bảo cấu trúc của XML tuân theo đúng định dạng đã được qui định giữa các ứng dụng trong quá trình giao tiếp

• Định nghĩa các ràng buộc giữa các thành phần trong cấu trúc tài liệu XML

• DTD không hỗ trợ xác định nội dung được đưa trong tài liệu XML là chính xác hay là không

• Internal: được nhúng trực tiếp vào tài liệu XML trong phần prolog với khai báo DOCTYPE – khai báo Document Type Declaration (ví dụ 1 trong bài Giới thiệu về XML – định nghĩa, cách viết XML đúng cú pháp (XML well-formed))

  • Cú pháp để khai báo và áp dụng trực tiếp vào tài liệu XML hiện hành

• Mục đích của DTD

• Phân loại DTD: có 02 loại

<!DOCTYPE name [<define elements, attributes, entity, and their relationships>]

• name: tên của root tag của tài liệu XML mà tài liệu DTD đang áp dụng

• External: DTD được lưu trữ dưới dạng file có phần mở rộng là dtd để khai báo cú pháp và không chứa khai báo Document Type Declaration và sau đó được nhúng vào tài liệu XML với khai báo DOCTYPE chỉ đến vị trí của file DTD

• Cú pháp để đưa tài liệu DTD áp dụng vào tài liệu XML hiện hành

<!DOCTYPE name SYSTEM “file|url”>

• name tương tự như định dạng Internal

• Từ khóa SYSTEM nhằm thể hiện ý nghĩa là DTD này không được công bố hay không được chia sẻ chung cho tất cả mọi người sử dụng, nghĩa là tài liệu DTD đang nằm tại máy hiện hành hay cục bộ

• Để tham chiếu đến tài liệu DTD được đưa để chia sẻ chung hay tham chiếu đến chuẩn chung của một DTD đã được public

<!DOCTYPE name PUBLIC FPI “url”>

• Cấu tạo của FPI – Formal Public Identifier như sau

Từ khóa	Định nghĩa
//	Phân cách giữa các thành phần trong FPI
Phần thứ 1	Thể hiện DTD có được viết trong dạng chuẩn hay không “-” chuẩn chưa được chấp nhận “+” chuẩn được chấp nhận nhưng nội dung không được viết theo chuẩn “chữ bất kỳ” chuẩn được chấp nhận và nội dung được viết theo chuẩn (ví dụ: ISO)
Phần thứ 2	Xác định tên cá nhân hay nhóm tác giả viết ra DTD
Phần thứ 3	Thể hiện loại tính chất hay phiên bản của tài liệu DTD được tham chiếu tới
Phần thứ 4	Xác định ngôn ngữ được dùng trong DTD, thể hiện bằng 02 ký tự theo chuẩn quốc tế

• Ví dụ

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

• Cấu trúc tài liệu DTD

  • Bao gồm các khai báo về tag – gọi là element, khai báo attribute, và khai báo entity (Phần entity này chúng tôi sẽ giới thiệu trong một chủ đề khác)

  • Các khai báo này không nhất thiết phải theo thứ tự mà có thể khai báo ở vị trí tùy ý vì bộ xử lý DTD có thể tìm kiếm tham chiếu đến tất cả các nơi trong tài liệu DTD để tìm ra định nghĩa nếu có

    • Nếu định nghĩa trùng lắp về element sẽ bộ parser sẽ thông báo lỗi trong khi kiểm tra tài liệu DTD sẽ không báo lỗi

    • Nếu định nghĩa trùng lắp về attribute và entity thì nội dung định nghĩa đầu tiên hay tham chiếu đầu tiên tìm thấy sẽ có hiệu lực áp dụng

  • Luật trên không thể áp dụng duy nhất đối với loại entity có tên là parameter entity, parameter entity phải được định nghĩa trước khi được sử dụng (trùng lắp vẫn được áp dụng đối parameter entity).

• Khai báo element hay tag

o Mỗi element khai báo bao gồm tên tag và nội dung kiểu dữ liệu được chứa đựng trong phần thân tag

o Tất cả các element tồn tại trong tài liệu XML phải được khai báo trong DTD

o Cú pháp: <!ELEMENT tên_tag content_model>

• Ví dụ: <!ELEMENT booktitle (#PCDATA)>

• Cú pháp thể hiện ràng buộc mối quan hệ giữa các element

• Các element không được định nghĩa trùng lắp. Nếu trùng lắp element, parser sẽ phát sinh lỗi khi áp dụng vào tài liệu XML, lỗi không phát sinh khi kiểm tra ngữ pháp trong DTD

<!ELEMENT tên_tag (khai báo các tag con bên trong, phân cách dấu “,”)[content_model]>

• Ví dụ: <!ELEMENT book (booktitle, author, price)+>

• Content model

§ Ký hiệu dấu ?: thể hiện số lần xuất hiện tag trong tài liệu tối thiểu là 0 lần, tối đa là 1 lần

§ Ký hiệu dấu +: thể hiện số lần xuất hiện tag trong tài liệu tối thiểu là 1 lần, tối đa là nhiều lần

§ Ký hiệu dấu *: thể hiện số lần xuất hiện tag trong tài liệu tối thiểu là 0 lần, tối đa là nhiều lần

§ Không có ký hiệu gì cả: thể hiện số lần xuất hiện bắt buộc là 1 lần

§ Khai báo tag với dạng a, b: thể hiện tag a rồi tag b

§ Khai báo tag dạng a | b: xuất hiện tag a hay tag b nhưng 02 tag này không thể xuất hiện cùng một lúc

§ Ký (): thể hiện 1 group hay group con trong trong khai báo

§ #PCDATA

• Xác định phần thân tag chứa đựng các ký tự được parse bởi bộ Parser.

• Cú pháp sử dụng (#PCDATA).

• Nếu sử dụng lồng ghép thì cú pháp #PCDATA phải được đứng đầu trong khai báo và không có ký hiệu ()

• EMPTY: xác định phần thân tag không được chứa ký tự hay nói cách khác đây là tag rỗng hay dùng XML cú pháp với empty tag

• ANY: xác định phần thân tag có thể chứa bất kỳ nội dung nào từ ký tự đến element trong khi #PCDATA không chứa tag lồng ở bên trong

• Khai báo các attribute cho một tag

• Cú pháp khai báo trong DTD

<!ATTLIST tên_tag tên_attribute Kiểu_dữ_liệu ràng_buộc_cho_attribute>

• Cú pháp này có thể dùng để khai báo nhiều hơn một thuộc tính, một bộ thuộc tính khai báo gồm 3 thành

tên_attribute Kiểu_dữ_liệu ràng_buộc_cho_attribute

• Do vậy, khi parse thì bộ Parser sau khi đọc 3 thành phần sẽ đọc 3 thành phần tiếp theo và coi như 3 thành phần tiếp theo đó là thuộc tính được khai báo tiếp theo

• Các ràng buộc cho attribute

Các ràng buộc	Mô tả
#REQUIRED	Không thiết lập giá trị khởi tạo nhưng thuộc tính phải bắt buộc tồn tại trong tài liệu XML
#IMPLIED	Không thiết lập giá trị khởi tạo nhưng thuộc tính này có hay không có cũng được khi sử dụng tài liệu XML
#FIXED “giá trị”	Giá trị hằng với các ký tự được thiết lập cho thuộc tính. Thuộc tính có thể được gán nhưng phải gán bắt buộc với giá trị hàng
“giá trị”	Gán giá trị khởi tạo với các ký tự cho thuộc tính nếu thuộc tính này không được sử dụng trong XML.

• Các kiểu dữ liệu của attribute

Kiểu dữ liệu	Mô tả
CDATA	Giá trị của thuộc tính sẽ là chuỗi ký tự và bộ parser không xử lý ký tự này
NMTOKEN	Giá trị của thuộc tính sẽ là một chuỗi ký tự chứa  các ký tự tuân thủ qui luật đặt tên tag ngoại trừ ký tự bắt đầu có thể là số
NMTOKENS	Giá trị của thuộc tính sẽ tập một hay nhiều NMTOKEN và được phân cách bằng white-space
ID	Giá trị của thuộc tính sẽ là giá trị chuỗi tuân theo luật đặt tên tag name và sẽ là duy nhất trong tài liệu XML
IDREF	Giá trị của thuộc tính sẽ là giá trị của một ID có tồn tại trong tài liệu XML
IDREFS	Giá trị của thuộc tính sẽ là tập hợp các ID có trong tài liệu và được phân cách bằng white-space
ENTITY	Giá trị của thuộc tính sẽ là tên của một entity không được parse trong tài liệu XML. Entity này đã được khai báo trong DTD dùng để valid cho tài liệu XML với từ khóa ENTITY
ENTITIES	Giá trị của thuộc tính sẽ là tập hợp các ENTITY phân cách nhau bởi white-space
NOTATION	Giá trị của thuộc tính sẽ là một nhãn dùng để tham chiếu đến một thông tin cần thiết như là tên tập tin, tên thư mục hay là đường dẫn … được khai báo trong cú pháp NOTATION trong tài liệu DTD
Enumeration	Giá trị của thuộc tính sẽ là tập hợp các giá trị thuộc tính tuân đúng qui luật đặt tên tag và phân cách nhau bởi dấu | vertical bars.

• Lưu ý

  • Kiểu NOTATION dùng để khai báo đến một đường dẫn hay một kiểu dữ liệu mà không thể nhúng vào tài liệu XML như hình ảnh, hay nói cách khác đó là kiểu MIME, kiểu nhị phân

  • Các kiểu dữ liệu qui định trong DTD nêu trên chưa xác định được cụ thể kiểu dữ liệu của attribute là kiểu gì tương tự như kiểu dữ liệu được khai báo trong các ngôn ngữ lập trình. Đây là một khuyết điểm mà sẽ được schema khắc phục

• Trong nội dung của toàn bộ DTD đã nêu trên chúng ta muốn hướng tới việc thiết lập kiểm tra ràng buộc và tính chính xác của tài liệu XML thông qua bộ parser và thiết lập cho bộ parser kiểm tra toàn vẹn trước khi gửi đến chương trình ứng dụng

Vận dụng các kiến thức về DTD ở trên để áp dụng vào xây dựng tài liệu DTD, sau đó dùng tài liệu DTD để kiểm tra tính ràng buộc cho tài liệu XML trong một số ví dụ bên dưới

• Yêu cầu

  • Nắm vững các khái niệm về XML (tham khảo lại bài Giới thiệu về XML – định nghĩa, cách viết XML đúng cú pháp (XML well-formed))

  • Nắm vững các khái niệm về DTD đã nêu ở trên

  • Tools sử dụng ở đây là Netbeans 6.9.1

  • JDK 6 update 22

• Các bước thực hiện

• Tạo Java Application hay Web Application

• Tạo file DTD dạng external

  • Click Menu File, New File, chọn XML trong Categories, và chọn DTD Entity trong File types

  • Click Next

• Đặt tên file trong filename và vị trí lưu file

• Click Next

• Nhấn nút Finish

• Tài liệu DTD xuất hiện với nội dung mặc định

• Netbeans không hỗ trợ hiện thị gợi ý khi gõ, do vậy chúng ta nên dùng ký hiệu tắt để gọi cho nhanh và chính xác. Kết hợp từ viết tắt và phím tab

• Để tham chiếu bảng gõ tắt, chúng ta chọn tools, chọn Options, chọn Code Templates

• Trong phần language chọn DTD và xem các từ gõ tắt để áp dụng

• Khi gõ xong rồi chúng ta nên kiểm tra cú pháp gõ DTD đúng hay sai,chúng ta nhấn phải chuột ngay trên DTD và chọn check DTD

• Sau đó tạo tập tin XML để gõ nội dung tương tự như bài Giới thiệu về XML – định nghĩa, cách viết XML đúng cú pháp (XML well-formed)

• Ngoài cách nêu trên để tạo external DTD, chúng tạo DTD nhúng trong  XML, chúng ta tạo tập tin XML để gõ nội dung tương tự như bài Giới thiệu về XML – định nghĩa, cách viết XML đúng cú pháp (XML well-formed)

• Ở đây chúng ta sẽ vẫn sử dụng cách check validation để kiểm tra tài liệu XML phù hợp với DTD được khai báo bằng cách nhấn phải chuột trực tiếp trong code XML, chọn Validate XML

• Các bài ví dụ hướng tới là sử dụng định nghĩa về DTD áp dụng cho cả 02 trường hợp đúng và sai so với khái niệm và sử dụng thực tế

• Các ví dụ

• Ví dụ 1

• Tài liệu validate so với DTD định nghĩa và đây là một ví dụ về DTD được nhúng trong tài liệu XML (internal)

  • Tài liệu áp dụng cho node library

  • Tag library có chứa book mà book có content model là *, do vậy chứa nhiều book, tối thiểu có thể không có book nào

  • Tag book chứa thứ tự tag booktitle, author và price, content model của 3 node con là dấu +, do vậy tối thiểu phải có 1 phần tử và tối đa sẽ có nhiều phần tử

  • Các tag booktitle, author, price chứa chữ được parser parse trong thân

• Ví dụ 2

• Tài liệu xml không validation vì tài liệu định có thứ tự tag trong book không đúng qui định theo DTD

• Ví dụ 3

• Tài liệu xml này không validation bởi vì có chứa nhiều hơn một book, trong khi content model của book không ghi gì cả nghĩa là duy nhất tồn tại 1 phần tử

• Ví dụ 4

• Ví dụ này đang thể hiện khái niệm về dữ liệu trong tag là ANY, được phép chứa các tag và dữ liệu mà không bị parser bắt lỗi

• Ví dụ 5

• Ví dụ này không validate bởi vì định nghĩa tag author với (ANY), cú pháp ANY không có (),do vậy parser hiểu rằng tag author sẽ chứa tag ANY bên trong đó

• Chúng ta thực hiện chỉnh sửa bỏ () bao ANY thì parser sẽ không báo lỗi

• Cách sửa thứ 2 là chúng ta định nghĩa thêm tag ANY như bên dưới

• Validate

• Ví dụ 6

• Tài liệu này không validate bởi vì tag author chỉ cho phép chữ không cho phép gì khác nhưng phần tài liệu XML lại dùng tag p chứa trong thân tag author

• Ví dụ 7

• Đây là ví dụ đặc biệt về sự cho phép định sử dụng tồn tại 1 trong nhóm giá trị thông qua ký hiệu | trong book với 2 phần price và discount

• Nội dung thể hiện trong book tồn tại thứ tự booktitle, author, sau đó là price hay discount đều được nhưng không thể tồn tại cả 2 price lẫn discount

• Tài liệu sẽ báo lỗi về validation khi sử dụng như sau

• Validate

• Ví dụ 8

• Tài liệu này không validate bởi vì tag price định nghĩa kiểu dữ liệu parsing là PCDATA nhưng thiếu # dẫn đến bộ parser hiểu rằng tag price phải chứa tag PCDATA

• Ví dụ 9

• Đây là một ví dụ về định nghĩa trùng lắp element, kiểm tra well-formed thì đạt nhưng khi kiểm tra validation thì không đạt bởi vì không cho phép định nghĩa element trùng trong phần định nghĩa của DTD

• Ví dụ 10

• Đây là một ví dụ về external DTD

• Tài liệu XML validation vì đã tuân thủ qui định trong DTD

• Ví dụ 11

• Đây là ví dụ về thiết lặp thuộc tính giá trị khởi tạo mặc định khi thuộc tính đó không tồn tại trong xml

• Tài liệu hoàn toàn validation cho dù gender không tồn tại và chúng ta view tài liệu xml trên trình duyệt thì sẽ thấy gender được đưa vào với giá trị mặc định được thiết lập trong DTD

• Ví dụ 12

• Tài liệu XML không validate vì tag flag là tag không chứa phần thân nhưng trong tài liệu lại đưa chữ vào thân

• Ví dụ 13

• Tài liệu không validate vì tag khai báo để áp dụng DTD vào root không phải là root của tài liệu hiện hành

• Ví dụ 14

• Tài liệu không validate vì khai báo DOCTYPE tồn tại trong DTD

• Ví dụ 15

• Tài liệu không validate vì thuộc tính type trong contact là bắt buộc phải tồn tại vì giá trị #REQUIRED

• Ví dụ 16

• Đây là ví dụ, khi viết DTD xong, ta check DTD với việc click phải chuột và check DTD

• DTD không đúng vì #PCDATA thiếu ()

• Ví dụ 17

• Tài liệu không validate vì lỗi định nghĩa #PCDATA thiếu () và tag book có nhiều hơn một trong khi content model chỉ là ?

• Ví dụ 18

• Đây là một ví dụ về việc khai báo sai trong DTD là có giá trị chọn lựa của gender là M hay F nhưng sau đó thiết lập khởi tạo là A nếu gender không được dùng trong xml

• Check DTD không báo lỗi gì cả

• Nhưng validate xml áp dụng và view trình duyệt sẽ báo lỗi

• Ví dụ 19

• Tài liệu DTD không đúng cú pháp vì thuộc tính gender chưa xác định kiểu dữ liệu của thuộc tính (nhóm 3 thành phần)

• Khắc phục lỗi của ví dụ trên

• Để flag mặc định không gán gì cả

• View

• Gán trị cho flag thì khi view giá trị sẽ là giá trị được gán thay thế giá trị mặc định

• Ví dụ 20

• Đây là một ví dụ cho thấy không thể gán nhiều hơn ràng buộc cho thuộc tính, 3 ba nhóm thuộc tính là duy nhất nghĩa là tại 1 thời điểm các default cho attribute chỉ tồn tại một trong nhóm qui định, không thể tồn tại tất cả

• Ví dụ 21

• Tài liệu không validate vì giá trị được gán cho gender luôn luôn là hằng số bằng A, gán F sẽ báo lỗi

• Khi không để gì cả, mặc định lấy hằng số A

• Ví dụ 22

• DTD không đúng cú pháp khai báo attribute vì thiếu kiểu dữ liệu cho thuộc tính

• Ví dụ 23

• DTD không đúng cú pháp vì sai định nghĩa attribute, chứa nhiều hơn 1 giá trị default

• Ví dụ 23

• Ví dụ về định nghĩa nhiều hơn một attribute cho một tag

• Ví dụ 24

• Định nghĩa tag trùng, check DTD hiệu lực nhưng check validation cho XML không validate

• Ví dụ 25

• Ví dụ về việc attribute hay element có thể định nghĩa bất kỳ đâu trong DTD không cần theo thứ tự

• Ví dụ 26

• Đây là ví dụ trộn lẫn giữa chữ và tag thay gì dùng ANY, chúng ta dùng như trên với #PCDATA kết hợp  với dấu |.

• Lưu ý: cần xem kỹ lý thuyết và những điều khi sử dụng #PCDATA

• Ví dụ 27

• Ví dụ về sử dụng ID và IDREF

• Nếu định nghĩa trùng lắp và tham chiếu không có thì tài liệu sẽ có lỗi

• Ví dụ 28

• Ví dụ về sử dụng NMTOKEN

• Nếu dữ liệu có khoảng trắng giữa thì parser hiểu là MNTOKENS và gây lỗi

• Chỉnh sửa cho phù hợp nếu muốn chứa nhiều hơn 1

• Ví dụ 29

• Đây là ví dụ chúng ta sử dụng lại DTD và override thuộc tính chúng ta mong muốn để tạo ra định dạng mới như thuộc tính assessment_type

• View

Chúc mừng các bạn đã hoàn tất và nắm các khái niệm về sử dụng DTD, cụ thể là khai báo element – tag và attribute, sau đó áp dụng để kiểm tra tính toàn vẹn trong tài liệu XML.

Chúng tôi hy vọng nội dung của bài này giúp ích các bạn trong việc giao tiếp giữa các ứng dụng về dữ liệu. Mặc dù các ví dụ trên chưa có thể thể hiện đầy đủ tất cả các khái niệm, nhưng qua các ví dụ trên, chúng tôi hy vọng đã có thể giúp các bạn hiểu được các khái niệm tổng quát nhất của DTD và cách thức áp dụng DTD để validation XML.

Rất mong sự góp ý chân thành và chia sẻ của quí vị về vấn đề này. Hẹn gặp lại quý vị ở các chủ đề liên quan đến XML từ khai báo DTD về entities.