XML hầu như luôn bị sử dụng sai mục đích

Ngôn ngữ XML được phát minh vào năm 1996. Ngay khi nó xuất hiện thì khả năng ứng dụng của nó đã bắt đầu bị hiểu lầm và đối với những mục đích mà họ đang cố gắng điều chỉnh nó, thì đó không phải là lựa chọn tốt nhất.

Không quá lời khi nói rằng phần lớn các lược đồ XML mà tôi từng thấy đều sử dụng XML không phù hợp hoặc không chính xác. Hơn nữa, việc sử dụng XML này đã thể hiện sự hiểu lầm cơ bản về nội dung của XML.

XML là một ngôn ngữ đánh dấu. Đây không phải là định dạng dữ liệu. Hầu hết các lược đồ XML rõ ràng đã bỏ qua sự khác biệt này, gây nhầm lẫn giữa XML với một định dạng dữ liệu, điều này cuối cùng dẫn đến sai lầm khi chọn XML vì đó là định dạng dữ liệu thực sự cần thiết.

Không đi sâu vào chi tiết, XML phù hợp nhất để chú thích các khối văn bản có cấu trúc và siêu dữ liệu. Nếu mục tiêu chính của bạn không phải là làm việc với một khối văn bản thì việc chọn XML khó có thể hợp lý.

Từ quan điểm này, có một cách đơn giản để kiểm tra xem lược đồ XML được tạo ra tốt như thế nào. Hãy lấy một tài liệu trong lược đồ dự định làm ví dụ và xóa tất cả các thẻ và thuộc tính khỏi nó. Nếu những gì còn lại không có ý nghĩa (hoặc nếu còn một dòng trống), thì lược đồ của bạn không được xây dựng chính xác hoặc đơn giản là bạn không nên sử dụng XML.

Dưới đây tôi sẽ đưa ra một số ví dụ phổ biến nhất về các mạch được xây dựng không chính xác.

<roоt>
  <item name="name" value="John" />
  <item name="city" value="London" />
</roоt>

Ở đây chúng ta thấy một ví dụ về một nỗ lực vô căn cứ và kỳ lạ (mặc dù rất phổ biến) nhằm diễn đạt một từ điển khóa-giá trị đơn giản trong XML. Nếu bạn xóa tất cả các thẻ và thuộc tính, bạn sẽ chỉ còn lại một hàng trống. Về cơ bản, tài liệu này, dù nghe có vẻ vô lý đến mức nào, vẫn là một chú thích ngữ nghĩa của một dòng trống.

<root name="John" city="London" />

Tệ hơn nữa, ở đây chúng ta không chỉ có chú thích ngữ nghĩa của một chuỗi trống như một cách diễn đạt từ điển xa hoa - lần này "từ điển" được mã hóa trực tiếp dưới dạng thuộc tính của phần tử gốc. Điều này làm cho tập hợp tên thuộc tính nhất định trên một phần tử không được xác định và động. Hơn nữa, nó cho thấy rằng tất cả những gì tác giả thực sự muốn thể hiện chỉ là một cú pháp khóa-giá trị đơn giản, nhưng thay vào đó, ông lại đưa ra một quyết định hoàn toàn kỳ lạ là áp dụng XML, buộc sử dụng một phần tử trống đơn giản làm tiền tố để sử dụng cú pháp thuộc tính. Và tôi rất thường xuyên gặp những kế hoạch như vậy.

<roоt>
  <item key="name">John</item>
  <item key="city">London</item>
</roоt>

Đây là điều gì đó tốt hơn, nhưng vì lý do nào đó, khóa là siêu dữ liệu còn giá trị thì không. Một cái nhìn rất lạ về từ điển. Nếu bạn loại bỏ tất cả các thẻ và thuộc tính, một nửa thông tin sẽ bị mất.

Một biểu thức từ điển chính xác trong XML sẽ trông giống như thế này:

<roоt>
  <item>
    <key>Name</key>
    <value>John</value>
  </item>
  <item>
    <key>City</key>
    <value>London</value>
  </item>
</roоt>

Nhưng nếu mọi người đã đưa ra quyết định kỳ lạ là sử dụng XML làm định dạng dữ liệu và sau đó sử dụng nó để sắp xếp từ vựng thì họ nên hiểu rằng những gì họ đang làm là không phù hợp và không thuận tiện. Các nhà thiết kế cũng thường nhầm lẫn khi chọn XML để tạo ứng dụng của mình. Nhưng thường xuyên hơn, họ làm cho vấn đề trở nên tồi tệ hơn bằng cách sử dụng XML một cách vô nghĩa theo một trong các dạng được mô tả ở trên, bỏ qua thực tế là XML đơn giản là không phù hợp với điều này.

Lược đồ XML tệ nhất? Nhân tiện, giải thưởng dành cho lược đồ XML tệ nhất mà tôi từng thấy, Nhận định dạng tệp cấu hình cung cấp tự động cho điện thoại điện thoại IP Polycom. Những tệp như vậy yêu cầu tải xuống các tệp yêu cầu XML qua TFTP,... Nói chung, đây là đoạn trích từ một tệp như vậy:

<softkey
        softkey.feature.directories="0"
        softkey.feature.buddies="0"
        softkey.feature.forward="0"
        softkey.feature.meetnow="0"
        softkey.feature.redial="1"
        softkey.feature.search="1"

        softkey.1.enable="1"
        softkey.1.use.idle="1"
        softkey.1.label="Foo"
        softkey.1.insert="1"
        softkey.1.action="..."

        softkey.2.enable="1"
        softkey.2.use.idle="1"
        softkey.2.label="Bar"
        softkey.2.insert="2"
        softkey.2.action="..." />

Đây không phải là trò đùa xấu của ai đó. Và đây không phải là phát minh của tôi:

• các phần tử chỉ được sử dụng làm tiền tố để đính kèm các thuộc tính, bản thân chúng có tên phân cấp.
• Nếu bạn muốn gán giá trị cho nhiều phiên bản của một loại bản ghi cụ thể, bạn phải sử dụng tên thuộc tính để thực hiện việc này. có chỉ mục.
• Ngoài ra, các thuộc tính bắt đầu bằng softkey., phải được đặt trên các phần tử <softkey/>, thuộc tính bắt đầu bằng feature., phải được đặt trên các phần tử <feature/> v.v., mặc dù thực tế là nó trông hoàn toàn không cần thiết và thoạt nhìn vô nghĩa.
• Và cuối cùng, nếu bạn hy vọng rằng thành phần đầu tiên của tên thuộc tính sẽ luôn giống với tên thành phần - không có gì giống như vậy! Ví dụ, thuộc tính up. phải được gắn vào <userpreferences/>. Thứ tự gắn tên thuộc tính vào các phần tử là tùy ý, gần như hoàn toàn.

Tài liệu hoặc dữ liệu. Thỉnh thoảng, ai đó lại làm điều gì đó hoàn toàn kỳ lạ bằng cách cố gắng so sánh XML và JSON—và do đó cho thấy rằng họ cũng không hiểu. XML là ngôn ngữ đánh dấu tài liệu. JSON là một định dạng dữ liệu có cấu trúc, vì vậy việc so sánh chúng với nhau cũng giống như cố gắng so sánh ấm với mềm.

Khái niệm về sự khác biệt giữa tài liệu và dữ liệu. Là một dạng tương tự của XML, chúng ta có thể lấy một tài liệu có thể đọc được bằng máy một cách có điều kiện. Mặc dù nó được dự định là có thể đọc được bằng máy, nhưng nó ám chỉ một cách ẩn dụ các tài liệu và từ quan điểm này thực sự có thể so sánh với các tài liệu PDF, thường không thể đọc được bằng máy.

Ví dụ, trong XML thứ tự của các phần tử rất quan trọng. Nhưng trong JSON, thứ tự của các cặp khóa-giá trị trong các đối tượng là vô nghĩa và không được xác định. Nếu bạn muốn có được một từ điển không có thứ tự gồm các cặp khóa-giá trị thì thứ tự thực tế mà các phần tử xuất hiện trong tệp đó không quan trọng. Nhưng bạn có thể hình thành nhiều loại dữ liệu khác nhau từ dữ liệu này. tài liệu, bởi vì có một thứ tự nhất định trong tài liệu. Nói một cách ẩn dụ, nó tương tự như một tài liệu trên giấy, mặc dù nó không có kích thước vật lý, không giống như bản in hoặc tệp PDF.

Ví dụ của tôi về cách biểu diễn từ điển XML thích hợp cho thấy thứ tự của các phần tử trong từ điển, trái ngược với cách biểu diễn JSON. Tôi không thể bỏ qua thứ tự này: tính tuyến tính này vốn có trong mô hình tài liệu và định dạng XML. Một số người có thể chọn bỏ qua thứ tự khi diễn giải tài liệu XML này, nhưng không có lý do gì để tranh cãi về điều này vì vấn đề này nằm ngoài phạm vi thảo luận về chính định dạng đó. Hơn nữa, nếu bạn làm cho tài liệu có thể xem được trong trình duyệt bằng cách đính kèm một biểu định kiểu xếp tầng vào nó, bạn sẽ thấy rằng các thành phần từ điển xuất hiện theo một thứ tự nhất định và không theo thứ tự nào khác.

Nói cách khác, một từ điển (một phần dữ liệu có cấu trúc) có thể được chuyển đổi thành n nhiều tài liệu có thể khác nhau (ở dạng XML, PDF, giấy, v.v.), trong đó n - số lượng kết hợp các phần tử có thể có trong từ điển và chúng tôi chưa tính đến các biến có thể có khác.

Tuy nhiên, cũng theo đó, nếu bạn chỉ muốn truyền dữ liệu thì việc sử dụng tài liệu có thể đọc được bằng máy sẽ không hiệu quả. Nó sử dụng một mô hình, trong trường hợp này là không cần thiết; nó sẽ chỉ gây cản trở. Ngoài ra, để trích xuất dữ liệu nguồn, bạn sẽ cần phải viết một chương trình. Hầu như không có ý nghĩa gì khi sử dụng XML cho một nội dung không được định dạng dưới dạng tài liệu tại một thời điểm nào đó (chẳng hạn như sử dụng CSS hoặc XSLT hoặc cả hai), vì đó là lý do chính (nếu không phải là duy nhất) để làm như vậy. vào mô hình tài liệu.

Hơn nữa, vì XML không có khái niệm về số (hoặc biểu thức Boolean hoặc các kiểu dữ liệu khác) nên tất cả các số được biểu thị ở định dạng này chỉ được coi là văn bản bổ sung. Để trích xuất dữ liệu, lược đồ và mối quan hệ của nó với dữ liệu tương ứng được thể hiện phải được biết. Bạn cũng cần biết khi nào, dựa trên ngữ cảnh, một thành phần văn bản cụ thể đại diện cho một số và cần được chuyển đổi thành số, v.v.

Do đó, quá trình trích xuất dữ liệu từ các tài liệu XML không quá khác biệt so với quá trình nhận dạng các tài liệu được quét có chứa, chẳng hạn như các bảng tạo thành nhiều trang dữ liệu số. Có, về nguyên tắc có thể làm điều này, nhưng đây không phải là cách tối ưu nhất, ngoại trừ biện pháp cuối cùng, khi hoàn toàn không có lựa chọn nào khác. Một giải pháp hợp lý là chỉ cần tìm một bản sao kỹ thuật số của dữ liệu gốc không được nhúng trong mô hình tài liệu kết hợp dữ liệu với cách trình bày văn bản cụ thể của nó.

Điều đó nói lên rằng, tôi không hề ngạc nhiên khi XML phổ biến trong kinh doanh. Lý do cho điều này chính xác là định dạng tài liệu (trên giấy) dễ hiểu và quen thuộc với doanh nghiệp và họ muốn tiếp tục sử dụng một mô hình quen thuộc và dễ hiểu. Vì lý do tương tự, các doanh nghiệp thường xuyên sử dụng tài liệu PDF thay vì các định dạng dễ đọc bằng máy hơn - bởi vì chúng vẫn bị ràng buộc với khái niệm trang in có kích thước vật lý cụ thể. Điều này thậm chí còn áp dụng cho các tài liệu khó có thể được in ra (ví dụ: tài liệu đăng ký PDF dài 8000 trang). Từ quan điểm này, việc sử dụng XML trong kinh doanh về cơ bản là biểu hiện của tính đa hình. Mọi người hiểu ý tưởng ẩn dụ của một trang in có kích thước giới hạn và họ hiểu cách tạo quy trình kinh doanh dựa trên các tài liệu in. Nếu đó là hướng dẫn của bạn, các tài liệu không có giới hạn kích thước vật lý có thể đọc được bằng máy—tài liệu XML—thể hiện sự đổi mới trong khi vẫn là một bản sao tài liệu quen thuộc và thoải mái. Điều này không ngăn cản họ duy trì cách trình bày dữ liệu không chính xác và quá đa dạng.

Cho đến nay, các lược đồ XML duy nhất mà tôi biết mà tôi thực sự có thể coi là cách sử dụng định dạng hợp lệ là XHTML và DocBook.

Nguồn: www.habr.com