Ưu điểm của XML so với ký hiệu S-biểu thức (-ish) là gì?


11

Tôi muốn hỏi một câu hỏi về ký hiệu XML và S-biểu thức (-ish). Biểu thức S khá cũ; chúng cũng thực sự đơn giản Chúng ta có thể xem xét hai hình thức có ý nghĩa như nhau, khác nhau về cú pháp:

(mã xml lấy từ wikipedia của Ba Lan )

<?xml version="1.0" encoding="UTF-8"?>
<ksiazka-telefoniczna kategoria="bohaterowie książek">
 <!-- komentarz -->
  <osoba charakter="dobry">
    <imie>Ambroży</imie>
    <nazwisko>Kleks</nazwisko>
    <telefon>123-456-789</telefon>
  </osoba>
  <osoba charakter="zły">
    <imie>Alojzy</imie>
    <nazwisko>Bąbel</nazwisko>
    <telefon/>
  </osoba>
</ksiazka-telefoniczna>

Phiên bản S-Expression (-ish):

(:version "1.0" :encoding "utf-8")
(ksiazka-telefoniczna :category "bohaterowie książek"
  ; komentarz(a comment)
  (osoba :charakter "dobry"
    (imie Ambroży)
    (nazwisko Kleks)
    (telefon 123-456-789))
  (osoba :charakter "zły"
    (imie Alojzy)
    (nazwisko Bąbel)
    (telefon)))

Phiên bản S-Expression ngắn gọn hơn nhiều. Chúng tôi tránh sự dư thừa bằng cách sử dụng các ký hiệu danh sách đơn giản, nhưng chúng tôi vẫn có thể xác định cú pháp để bao gồm những thứ mà chúng tôi muốn có (ví dụ: thuộc tính). Tất nhiên, đây chỉ là một ví dụ, và tiêu chuẩn thực tế có thể tốt hơn hoặc đơn giản là khác nhau; tuy nhiên, nó ngắn hơn và dễ phân tích hơn. Tại sao XML thắng?



5
Đối với những người downvoters: đừng downvote nếu bạn không đồng ý với câu hỏi, nhưng nếu bạn nghĩ nó có chất lượng kém (và sau đó, hãy đề xuất thay đổi để cải thiện chất lượng). @RobertHarvey Nếu bạn nghĩ rằng đó là một câu trả lời, xin vui lòng, trả lời câu hỏi của tôi thay vì bỏ một bình luận.
MatthewRock

1
Chú giải công cụ qua nút downvote bao gồm cụm từ "câu hỏi này không cho thấy bất kỳ nỗ lực nghiên cứu nào."
Robert Harvey

1
Hãy cố gắng nhớ rằng đây không phải là một diễn đàn thảo luận. Câu hỏi thực sự có câu trả lời, và các thành viên cộng đồng dự kiến ​​sẽ cung cấp câu trả lời, không phải ý kiến.
Robert Harvey

1
Các đối số dự phòng cho XML (như có dấu ngoặc đóng với tên của dấu ngoặc mở) có thể dễ dàng được mô phỏng bằng biểu thức S. Đơn giản chỉ cần viết (para "This is a paragraph " (footnote "(better than the one under there)" "." /footnote) /para).
Andrew

Câu trả lời:


13

Chúng tôi biết các nhà thiết kế XML đã quen thuộc với biểu thức S, vì XML dựa trên SGML và SGML có ngôn ngữ biểu định kiểu, DSSSL, sử dụng cú pháp biểu thức S (và lược đồ làm ngôn ngữ kịch bản nhúng).

Tuy nhiên, họ đã chọn một cú pháp khác với biểu thức S do các trường hợp sử dụng cho XML. XML ban đầu được thiết kế để hỗ trợ cả ngôn ngữ có cấu trúc và dữ liệu được tạo bằng máy như HTML, được soạn thảo thủ công và chứa nội dung hỗn hợp (văn bản xen kẽ với các yếu tố với siêu dữ liệu).

Tài liệu văn bản đánh dấu thường dài hơn một màn hình. Nếu bạn thấy a )và bạn không thể thấy phần đầu của cấu trúc, bạn sẽ khá lạc lõng; bạn không biết liệu đó là một chương hay một thanh bên vừa kết thúc. Sự dư thừa của việc lặp lại tên thẻ trong endtags trong XML như </sidebar>làm cho điều này dễ dàng hơn nhiều đối với người viết. Nó cũng làm cho nó mạnh mẽ hơn: nếu bạn vô tình xóa thẻ kết thúc, bạn có thể thường xuyên suy ra thẻ kết thúc nào bị thiếu.

SGML (tiền thân của XML) cho phép bạn tùy ý rút ngắn thẻ kết thúc thành một ký tự, nhưng tính năng này bị loại bỏ khỏi XML vì đơn giản.

Vì vậy, trong ngắn hạn, XML dài hơn theo thiết kế, bởi vì nó được thiết kế để hỗ trợ tài liệu có thể chỉnh sửa của con người. Ngày nay, XML được sử dụng cho nhiều mục đích khác nhau, cũng cho giao tiếp giữa máy với máy thuần túy, nơi không cần dự phòng này.

Nội dung hỗn hợp

Cú pháp đề xuất của bạn sẽ không hỗ trợ nội dung hỗn hợp rất tốt. Lấy ví dụ này trong HTML:

<p>Hi! <a href="example.com">Click here</a>!</p>

Làm thế nào bạn sẽ thể hiện điều này trong cú pháp của bạn? Bạn sẽ cần một số loại dấu phân cách bổ sung để phân biệt giữa các thuộc tính và nội dung văn bản. Đột nhiên nó không còn súc tích nữa.

Nhân vật đặc biệt

Dấu ngoặc góc hiếm hơn nhiều trong văn bản thông thường so với dấu ngoặc đơn và dấu hai chấm.

Khả năng tương thích

HTML đã thành công rực rỡ tại thời điểm XML được thiết kế và thật hợp lý khi chọn một cú pháp tương tự.

Tại sao XML thắng?

Biểu thức S không bao giờ là một thay thế cho XML. Thông số XML nhiều hơn dấu ngoặc nhọn; Nó định nghĩa một cú pháp cho các thành phần và thuộc tính và nội dung hỗn hợp, thoát, mã hóa ký tự, cú pháp DTD và xác nhận, v.v. Không có gì tương tự tồn tại cho biểu thức s. Tất nhiên bạn có thể định nghĩa một tiêu chuẩn tương tự, như bạn đề xuất ở đây, nhưng không ai đã làm điều này vào thời điểm đó. XML được W3C ban phước và do đó được những người chơi lớn chấp nhận và trở thành tiêu chuẩn defacto để trao đổi dữ liệu.


3
Trong ví dụ của mình, không phải dấu hai chấm được sử dụng cho các thuộc tính? Ví dụ. (p Xin chào! (a: href "example.com" Bấm vào đây)!)? (hoặc anh ấy chỉ chỉnh sửa nó sau khi câu trả lời của bạn được đăng?)
Headcrab

Mặc dù không có gì khác với câu trả lời (xuất sắc) của bạn, ai là người có suy nghĩ đúng đắn sẽ tự tạo tài liệu XML?
Jared Smith

Này Jacques, cảm ơn vì câu trả lời tuyệt vời này! Tôi đồng ý với Headcrab rằng nội dung hỗn hợp không phải là vấn đề. Tôi cũng đồng ý với Jared, mặc dù tôi đoán rằng đôi khi XML được đọc / ghi thủ công.
MatthewRock

@Headcrab: Thật khó để nói vì không có thông số thực tế, chỉ là một ví dụ giả thuyết. Nhưng dường như tôi đại diện cho văn bản là biểu tượng chứ không phải là một chuỗi trích dẫn sẽ dẫn đến sự mơ hồ với khoảng trắng. Biểu thức S không hỗ trợ khoảng trắng đáng kể giữa các nguyên tử AFAIK, nhưng bạn cần điều này để hỗ trợ, ví dụ như <PRE>phần tử trong HTML. Vì vậy, tôi giả sử trích dẫn sẽ là cần thiết.
JacquesB

2
Vì vậy, nó thực sự trông giống như XML được tạo ra với tất cả các chuông và còi và cú pháp giống như HTML quen thuộc đã giúp nó giành chiến thắng trước các biểu thức s vào thời điểm đó. Vào thời điểm nhiều nhà phát triển quyết định rằng, trong các trường hợp sử dụng của họ, tất cả các tính năng này không thực sự cần thiết cho giao tiếp giữa máy với máy, có một sự thay thế nhẹ khác dưới dạng JSON.
kamilk

9

Cá nhân, tôi nghĩ phần hay nhất về XML là các khả năng lược đồ được xác định rõ, thay vì cú pháp của nó. Cơ chế lược đồ cho phép người dùng xuất bản định dạng tài liệu của họ để chia sẻ những gì họ cho là tài liệu hợp lệ. Ngoài ra còn có trình xác nhận tự động. Ngoài ra, các loại và lược đồ được tạo bởi một người dùng có thể được mở rộng bởi những người dùng khác.

Theo như tôi biết, không ai đã thực hiện bất kỳ nơi nào gần nỗ lực chuẩn hóa cơ chế lược đồ mục đích chung cho biểu thức s, ngoại trừ chính ngôn ngữ LISP (mà mẫu trong câu hỏi của OP không sử dụng).


1
Mặc dù tôi không thích tính dài dòng của XML, +1 khi đề cập đến các khả năng lược đồ gần như làm cho nó có giá trị. :-)
user949300


1

Đây là hai lý do mà tôi sẽ chọn XML thay vì "S-biểu hiện-ish":

Một mô hình cú pháp và ngữ nghĩa được xác định rõ

XML không chỉ đơn giản là một cây của các nút, mà là một cây của các nút được phân loại có biểu diễn cú pháp khác nhau và hành vi khác nhau. Ví dụ: một thuộc tính có tên đã cho chỉ có thể xuất hiện một lần cho một nút nhất định, trong khi các nút con có thể xuất hiện nhiều lần.

Bạn có thể định nghĩa một mô hình như vậy trên đầu các biểu thức S chung. Các ví dụ của bạn hiển thị một sơ đồ để phân loại các thuộc tính và các phần tử con. Thêm vào ngữ nghĩa cho văn bản, nhận xét và hướng dẫn xử lý và bạn sẽ có một cái gì đó tương đồng với XML.

Dụng cụ

Từ mô hình cú pháp và ngữ nghĩa chuẩn, bạn có thể xây dựng các công cụ - và rất nhiều người có. Bạn có thể tìm thấy một số dạng bộ phân tích cú pháp / bộ tuần tự XML, bộ xử lý XPath và XSLT cho mọi ngôn ngữ / nền tảng chung. Và bạn biết rằng tất cả họ sẽ hành xử giống nhau trên mọi nền tảng.


Và đây là một vài điều khác để xem xét:

Trong lược đồ lớn, XML không dài dòng

Trong ví dụ của bạn, những gì bạn đã thực sự loại bỏ? Khi tôi đọc nó, bạn đã:

  • Loại bỏ thẻ đóng cho mỗi biểu thức.
  • Loại bỏ cái >mà thông thường sẽ tách thẻ mở ra khỏi con của nó.
  • Thay thế =phân tách tên và giá trị thuộc tính bằng a :để chỉ ra rằng đứa trẻ là một thuộc tính; không tiết kiệm.

Tôi nghĩ điều quan trọng là phải nhận ra rằng các biểu diễn bên trong và bên ngoài của XML rất khác nhau. Trong nội bộ, một cây XML rất nhỏ gọn. Và bởi vì các yếu tố khác nhau đã được phân loại, thao tác rất hiệu quả. Bên ngoài, tốt, vâng, bạn nhận được tất cả các thẻ đóng, nhưng chúng nén tốt.

"Độ dài" là vấn đề thực sự?

Tôi nghĩ rằng câu hỏi thực sự không phải là liệu XML có "dài dòng" hay không, mà là nó có ý nghĩa hơn là cần thiết cho một mục đích nhất định hay không. Vài ví dụ:

  • Khả năng cho một phần tử giữ các thuộc tính, khác biệt về mặt ngữ nghĩa với các phần tử con. Hữu ích cho thông tin ngoài băng, chẳng hạn như mô tả loại dữ liệu gốc, nội dung của thành phần. Nhưng có lẽ bạn không cần điều đó, bởi vì thông số bên ngoài của bạn xác định nội dung.
  • Nội dung hỗn hợp, trong đó một phần tử có thể chứa cả phần tử con và văn bản (cũng như nhận xét và hướng dẫn xử lý). Hữu ích cho đánh dấu, nhưng có lẽ không phải để biểu diễn dữ liệu đơn giản.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.