Cấu trúc của một tập tin XML bao gồm các thẻ tag và các thuộc tính attribute . Cấu trúc này được thẻ hóa tokenized trong XMill như sau: các thẻ bắt đầu được mã hóa từ
điển tức là được gán bởi một giá trị số nguyên trong khi tất cả các thẻ kết thúc được thay thế bằng ký tự “/”, các giá trị dữ liệu được thay thế với chỉ số bộ chứa container number của chúng.
Hình 3.2: Mô tả quá trình XMill phân tách cấu trúc và dữ liệu Ví dụ 3.1: Minh họa cấu trúc một tập tin XML đơn giản như sau:
<book> <b> <c>text1</c> </b> <b> <c>text1</c> </b> <c>text3</c> <d>text4</d> </book>
Hình 3.2 mô tả chi tiết quá trình XMill phân tách cấu trúc và dữ liệu của tập tin XML trong ví dụ 3.1.
3.1.2.2. Nh m các giá trị dữ liệu dựa trên ngữ nghĩa
Mỗi giá trị dữ liệu được gán cho một container duy nhất. Quá trình ánh xạ từ giá trị dữ liệu đến container được xác định bởi đường dẫn của giá trị dữ liệu và các biểu thức chứa (container expression) được chỉ định bởi người sử dụng.
Đường d n: đường dẫn đến một giá trị dữ liệu là chuỗi các thẻ từ gốc tới giá trị. Trong ví dụ 3.1, đường dẫn của text1 là /a/b/c, text3 là /a/c; text4 là /a/d.
iểu thức chứa (container expression): tạo ra một bộ chứa cho mỗi thẻ hoặc mỗi một thuộc tính. Bộ chứa được quyết định bởi thẻ hoặc thuộc tính cuối cùng trong đường dẫn. Quá trình ánh xạ từ đường dẫn đến biểu thức bộ chứa được mô tả qua các biểu thức chính quy (regular expression . Xem xét các biểu thức chính quy được dẫn xuất từ XPath:
c::=label|*|#|e1/e2|e1//e2|(e1|e2)|(e)+
Trong đó:
label: thẻ hoặc thuộc tính.
*: biểu thị bất kỳ thẻ hoặc thuộc tính.
e1/e2: phép ghép nối e1 đến e2, giữa e1 và e2 không có bất kỳ đường dẫn nào ở giữa.
e1//e2: phép ghép nối e1 đến e2 với bất kỳ đường dẫn ở giữa. (e1|e2 : e1 hoặc e2.
(e +: e xuất hiện một hay nhiều lần.
#: viết tắt cho bất kỳ thẻ hoặc thuộc tính giống như *, nhưng mỗi sự xuất hiện của # sẽ quyết định một container mới.
Một container expression có dạng c::=/e|e//. Trong đó, e khớp với e đầu tiên bắt đầu từ gốc cây XML, //e khớp với e ở bất kỳ độ sâu tùy ý. Ở dây //* được viết tắt bởi //.
Ví dụ 3.2: Xét các biểu thức sau: // Name
//Person/Title //
Trong ví dụ 3.2, //Name tạo ra một container cho tất cả giá trị dữ liệu mà đường dẫn của nó bằng Name. //Person/Title tạo ra một container cho tất cả các title của Person. // lưu giữ tất cả các mục dữ liệu data item trong một container riêng.
Ví dụ 3.3: Xét biểu thức sau: /#
Trong ví dụ 3.3, /# tạo ra một họ container, mỗi container cho mỗi thẻ kết thúc hoặc thuộc tính. Đây là một các biểu diễn ngắn gọn toàn bộ một tập hợp các biểu thức chứa: //Title, //@language, //Name ... một container cho từng thẻ tag trong tập tin XML .
Ví dụ 3.4: Xét các biểu thức sau: //Person/#
//#/# (#)+
Trong ví dụ 3.4, //Person/# tạo ra một container riêng cho mỗi thẻ nằm dưới Person, //#/# tạo ra một bộ chứa riêng cho hai thẻ cuối cùng, # + tạo một bộ chứa riêng cho mỗi đường dẫn.
Các biểu thức chứa container expression) c1..., cn được đưa ra trong d ng lệnh với tham số p:
Mỗi một giá trị dữ liệu, Path Processor sẽ khớp các đường dẫn của nó dựa vào c1, c2 ... theo thứ tự. Giả sử tìm thấy sự phù hợp match đầu tiên tại ci: bộ xử lý tính toán “các giá trị” của # trong ci. Các giá trị này xác định duy nhất bộ chứa của giá trị dữ liệu.
Ví dụ 3.5: Xét hai d ng lệnh sau: xmill -p //# file.xml file.xmi
xmill -p //Person/Title -p //Person/(Name|Child) -p //# file.xml file.xmi
Nhóm đầu tiên nhóm và nén các giá trị dữ liệu dựa vào thẻ kết thúc. Nhóm thứ hai nén tất cả các title của Person với nhau, tất cả name của Person và child của nó được nén chung nhau, và tất cả các giá trị dữ liệu khác được nén dựa vào thẻ kết thúc của nó. Trong thực tế, Doc/Book/Title và /Doc/Conference/Paper/Title được nén cùng nhau và riêng rẽ từ /Doc/Person/Title.
Ví dụ 3.6: Xem xét d ng lệnh sau: xmill file.xml file.xmi
bằng d ng lệnh:
xmill -p //# file.xml file.xmi
“-p //#” mặc định luôn luôn được chèn vào cuối d ng lệnh. Điều này đảm bào rằng tất cả cả giá trị dữ liệu được lưu trữ ít nhất trong một container, và cung cấp một hành vi mặc định phù hợp khi người dùng không chỉ định bất kỳ một container expression nào.
Ngữ nghĩa hình thức (formal semantic): bảng 3.1 đưa ra một biểu thức chứa c và một đường dẫn p, hàm Match c, p tính toán một tập hợp các chuỗi ký hiệu các phép gán có thể từ #. Có một sự phù hợp match khi và chỉ khi hàm Match c, p # . Match(c, p) có thể trả về nhiều hơn một kết quả. Trong bảng 3.1, ký hiệu cho chuỗi rỗng, / ký hiệu cho quá trình ghép nối chuỗi. Nếu ci với i=1… n, là container expression đầu tiên khớp match với p, thì giá trị dữ liệu với đường dẫn p sẽ được lưu trữ trong một container duy nhất được định nghĩa bởi i, Match c, p .
ảng 3.1: Định nghĩa hàm Match(c, p) [11]
Match(|e,p) = Match(e,p) Match(#,l) = {l}
Match(||e,p) = q/p1=pMatch(e,p1) Match(e1/e2,p)=p1/p2=pMatch(e1,p1)/ Match(e2,p2) Match(l,l) = {} Match(e1/e2,p)= p1/q/p2=pMatch(e1,p1)/
Match(e2,p2)
Match(l1,l2) = if l1 # l2 Match(e1|e2,p)=Match(e1,p)Match(e2,p) Match(*,l) = {} Match((e)+,p)= p1/p2…/pn=pMatch(e,p1 / …/
Ví dụ 3.7: Xem xét đường dẫn p=/Doc/Conf/Paper/Title cho ra kết quả như sau: Match(/Doc/Title,p) = {} Match(//#/#,p) = {Paper/Title}
Match /Doc//Title,p = {ε} Match(/(#),p) = {Doc/Conf/Paper/Title} Match(//#,p) = {Title} Match(//#//Title,p) = {Doc,Conf,Paper}
3.1.2.3. Các bộ nén ngữ nghĩa
XML thường được dùng để biểu diễn các loại dữ liệu như số nguyên, ngày tháng, mã sân bay… mà được nén tốt nhất bởi các bộ nén ngữ nghĩa có tính chuyên môn hóa (specialized semantic compressor).
Có 3 loại bộ nén ngữ nghĩa bao gồm bộ nén ngữ nghĩa nguyên tử, bộ nén ngữ nghĩa kết hợp và bộ nén ngữ nghĩa do người dùng tự định nghĩa.
ộ nén ngữ nghĩa nguyên tử (automic semantic compressor): có tám bộ nén ngữ nghĩa nguyên tử được mô tả trong bảng 3.2.
ảng 3.2: Các bộ xử lý ngữ nghĩa nguyên tử (Atomic Semantic Compressors) [11] ộ nén (compressor) Mô tả
t Bộ nén văn bản mặc định .
u Bộ nén số nguyên dương.
i Bộ nén số nguyên.
u8 Bộ nén số nguyên dương <256.
di Bộ nén delta cho số nguyên.
ri Run-length code.
e Mã hóa từ điển liệt kê.
“…” Bộ nén hằng số.
Bộ nén văn bản t không nén nhưng sao chép chuỗi ký tự đến bộ chứa, nó sẽ được nén bởi gzip sau đó.Trong bộ nén u, các số nguyên dương được mã hóa nhị phân như sau: các số nhỏ hơn 128, sử dụng 1 byte, các số nhỏ hơn 16384 sử dụng 2 bytes, các trường hợp c n lại sử dụng 4 bytes. Các số nguyên có dấu trong bộ nén i được lưu trữ giống bộ nén u. Bộ nén số nguyên u8 lưu trữ một số giữa 0 và 255 trong 1 byte đơn lẻ. Bộ nén delta delta compressor) áp dụng cho số nguyên, lưu trữ sự khác nhau giữa các số liên tiếp. Bộ mã hóa run-length mã hóa chuỗi có những giá trị dữ liệu giống nhau như các cặp val, count . Bộ mã hóa liệt kê e enumeration encoder sẽ gán một số nguyên dương cho mỗi giá trị dữ liệu mới và giữ một từ điển của tất cả các giá trị trước đó. Bộ nén hằng constant compressor không tạo ra bất kỳ đầu ra nào nhưng kiểm tra đầu vào là hằng số, điều này đặc biệt hữu ích trong các bộ nén kết hợp combined compressor .
Các bộ nén ngữ nghĩa thường được xác định trong các d ng lệnh như sau:
Trong đó, c là một biểu thức chứa container expression và s là một bộ nén ngữ nghĩa. Khi bị thiếu bộ nén mặc định là bộ nén ngữ nghĩa văn bản.
Ví dụ 3.8: Xét d ng lệnh sau:
xmill -p //price=>i -p //state=>e -p //description// file.xml file.xmi
Dữ liệu price được nén như các số nguyên, state như các giá trị liệt kê, và text nằm dưới description bất kể độ sâu nào được đặt trong bộ chứa riêng sử dụng bộ nén ngữ nghĩa. Tất cả dữ liệu c n lại được nhóm dựa trên các thẻ của cuối cùng và không sử dụng nén ngữ nghĩa.
Bộ nén được kết hợp (Combined compressor): XMill có ba sự kết hợp bộ nén như sau:
Bộ nén tuần tự Sequence Compressor : seq s1 s2 ... hoặc một biến thể khác là seqcomb s1 s2... . Ví dụ u8 “.”u8“.”u8“.”u8 nén một địa chỉ IP như 4 số nguyên.
Bộ nén luân phiên Alternate Compressor or s1 s2 ... . Một bộ nén kết hợp là or seq u u u hoặc một biến thể khác là orcomb s1 s2 ... .
Bộ nén lặp Repetition Compressor hoặc rep d s . Ở đây d là dấu phân cách delimiter , và s là một bộ nén ngữ nghĩa khác. Ví dụ, một chuỗi dấu phẩy được tách ra từ các từ khóa có thể được nén bởi rep "," e .
Ví dụ 3.9: Minh họa việc sử dụng các bộ nén ngữ nghĩa kết hợp cho dữ liệu Weblog. -p//apache:host=>seqcomb u8 ”.” u8 ”.” u8 ”.” u8 -p//apache:userAgent=>seq(e "/" e) -p//apache: byteCount=>u -p//apache:statusCode=>e -p//apache:contentType=>e -p//apache:requestLine=>seq("GET " rep("/" e) " HTTP/1." e) -p//apache:date=>seq u "/" u8 "/" u8 “-” u8 “:” di “:” di
-p//apache:referer=>or seq "file:" t seq “http://" or seq rep "." e "/" rep "/" e rep "." e))) t)
ộ nén ngữ nghĩa do người dùng tự định nghĩa (User-defined Compressor): một số ứng dụng đ i hỏi các bộ nén có tính chuyên môn hóa cao như các chuỗi DNA, người dùng có thể viết ra các bộ nén/ giải nén của riêng mình và liên kết chúng vào trong XMill và XDemill bằng cách cài dặt sử dụng SCAPI Semantic Compressor API . API yêu cầu người dùng cài đặt một số phương thức C++ và định nghĩa bộ nén với tên duy nhất.
Ví dụ 3.10: Giao diện SCAPI cho quá trình cài đặt các bộ nén ngữ nghĩa class UserCompressorFactory {
virtual char *GetName()=0;
virtual UserCompressor *InstantiateCompressor (char *paramstr, int len)=0;
virtual UserDecompressor *InstantiateDecompressor(char *paramstr, int len)=0;
};
class UserCompressor {
virtual unsigned GetContainerNum()=0; virtual bool IsRejecting()=0;
virtual bool ParseString (char *
str, int len, void *state)=0;
virtual void CompressString(char *str, int len,
Container *contarray, void *state)=0; class
virtual void FinishCompress(Container *contarray, void *state)=0;
};
class UserDecompressor {
virtual void DecompressItem(DecomprCont *contarray, XMLOutput *output, void *state)=0;
};
3.2. XGrind
3.2.1. Tổng quan về XGrind
XGrind thuộc nhóm kỹ thuật nén XML đồng cấu có khả năng truy vấn và phụ thuộc vào thông tin lược đồ. XGrind nén giá trị của các phần tử, thuộc tính bằng cách sử dụng một giản đồ nén phi ngữ cảnh context-free compression scheme đơn giản dựa trên mã hóa Huffman. Điều này có nghĩa là XGrind có thể thực hiện truy vấn trên tài liệu nén mà không cần phải giải nén toàn bộ tài liệu.
Một điểm đặc trưng và đặc biệt của XGrind là tài liệu nén giữ lại cấu trúc ban đầu của tài liệu gốc bởi vì XGrind không phân tách riêng rẽ phần cấu trúc và dữ liệu. Tài liệu nén có thể được phân tích cú pháp bằng cách sử dụng chính xác các kỹ thuật tương tự mà được sử dụng cho phân tích cú pháp của tài liệu XML gốc.
Điểm nổi bật thứ hai là các chỉ mục XML XML indexes có thể được tạo ra trên tài liệu nén.
Đặc điểm thứ ba của XGrind là có thể cập nhật trực tiếp dữ liệu XML trên các phiên bản nén. Đặc điểm cuối cùng là có thể sử dụng DTD để kiểm tra tính hợp lệ validity đối với tài liệu nén hoặc tăng cường tỷ lệ nén.
3.2.2. Các kỹ thuật nén được sử dụng trong XGrind
XGrind sử dụng các kỹ thuật khác nhau cho nén siêu dữ liệu meta-data , giá trị thuộc tính loại liệt kê enumerated-type attribute , và giá trị của phần tử hoặc thuộc tính tổng quát chung.
3.2.2.1. Quá trình nén siêu dữ liệu
Các thẻ bắt đầu của một phần tử được mã hóa bởi ký tự „T‟ theo sau bởi một phần tử được gán giá trị duy nhất – ID. Tất cả các thẻ kết thúc được mã hóa bởi ký tự “/”. Tên của
các thuộc tính được mã hóa bởi ký tự “A” và theo sau là một thuộc tính được gán giá trị duy nhất – ID.
3.2.2.2. Quá trình nén giá trị của thuộc tính kiểu liệt kê
Giá trị của thuộc tính loại liệt kê xuất hiện phổ biến trong các tài liệu XML. Ví dụ như: thành phố, bang của một quốc gia, tập hợp các ph ng ban của công ty, mã bưu điện zipcode … Giá trị liệt kê thường được khai báo trong DTD. XGrind nhận biết các thuộc tính liệt kê bằng cách kiểm tra DTD của tài liệu và mã hóa các giá trị của chúng bằng cách sử dụng một lược đồ mã hóa log2K đơn giản để biểu diễn một miền của các giá trị K được liệt kê.
3.2.2.3. Quá trình nén giá trị của phần tử hoặc thuộc tính tổng quát
Mục tiêu của XGrind đó là thực hiện hiệu quả truy vấn tài liệu nén. Vì vậy cần thiết phải có một giản đồ nén phi ngữ cảnh context-free compression schema , tức là một giản đồ nén mà trong đó mỗi chuỗi trong tài liệu được gán một mã code độc lập về vị trí của nó trong tài liệu. Tính năng này cho phép xác định vị trí xuất hiện của một chuỗi bất kỳ một cách trực tiếp trong tài liệu nén mà không cần phải giải nén tài liệu.
Quá trình nén phi ngữ cảnh không thể thực hiện được với các thuật toán động (adaptive algorithms như LZ77 vì mã code được gán cho một mục dữ liệu data item phụ thuộc vào toàn bộ nội dung đã xuất hiện trước đó, nghĩa là khi thực hiện một truy vấn cho một chuỗi thì phải giải nén toàn bộ nội dung phía trước nó. Mặt khác, quá trình nén phi ngữ cảnh có thể thực hiện được với các phiên bản tĩnh non-adaptive của thuật toán Huffman và mã hóa số học Arithmetic Coding [12]). XGrind sử dụng thuật toán non-adaptive Huffman. Để hỗ trợ cho tính năng non-adaptive phải thực hiện hai bước chuyển đổi tài liệu XML: bước thứ nhất thu thập thống kê và bước thứ hai thực hiện quá trình mã hóa.
XGrind sử dụng một bảng phân bổ tần số riêng biệt cho mỗi phần tử hoặc thuộc tính không liệt kê bởi vì các dữ liệu thuộc về cùng một phần tử hay một thuộc tính thường có liên quan về mặt ngữ nghĩa và được dự kiến là sẽ có sự phân bố giống nhau.
Với lược đồ phi ngữ cảnh, các truy vấn có thể thực hiện trên tài liệu nén mà không cần giải nén toàn bộ tài liệu. Chính xác hơn là, các truy vấn tìm kiếm chính xác exact-match khóa tìm kiếm là một giá trị cụ thể và tìm kiếm theo tiền tố prefix-match khóa tìm kiếm là một tiền tố của các giá trị dữ liệu được thực hiện hoàn toàn trực tiếp trên tài liệu nén. Trong khi đó, tìm kiếm theo phạm vi range-match khóa tìm kiếm bao phủ một loạt các giá trị dữ liệu hoặc tìm kiếm từng phần partial-match khóa tìm kiếm là một chuỗi con của các giá trị dữ liệu lại yêu cầu quá trình giải nén thực hiện ngay nhanh chóng chỉ trên các giá trị của phần tử hoặc thuộc tính mà là một phần của biểu thức truy vấn.
3.2.3. Nén đ ng cấu (Homomorphic Compression)
Tính năng nổi bật của chương trình nén XGrind là tài liệu đầu ra của nó vẫn giữ nguyên cấu trúc giống như tài liệu đầu vào. Thực tế, tài liệu nén XML có thể được hiển thị