Chúng ta có thể thay thế hoàn toàn XML bằng JSON không? [đóng cửa]

Tôi chắc chắn rất nhiều nhà phát triển đã quen thuộc với XML và JSON và họ đã sử dụng cả hai. Do đó, không có lý do nào để giải thích chúng là gì và mục đích của chúng là gì, thậm chí là ngắn gọn.

Nếu chúng ta cố gắng ánh xạ các khái niệm của họ, chúng ta có thể nói (sửa tôi nếu tôi sai):

1. Các thẻ XML tương đương với JSON {}
2. Các thuộc tính XML tương đương với các thuộc tính JSON
3. Bộ sưu tập thẻ XML tương đương với JSON []

Điều duy nhất tôi có thể nghĩ, không tồn tại trong JSON, là Không gian tên XML .

Câu hỏi đặt ra là, khi xem xét ánh xạ này và xem xét rằng JSON rất nhẹ trong ánh xạ này, chúng ta có thể thấy một thế giới trong tương lai (hoặc ít nhất là về mặt lý thuyết nghĩ về một thế giới) không có XML, nhưng với JSON thì mọi thứ đều làm XML? Chúng ta có thể sử dụng JSON ở mọi nơi XML được sử dụng không?

PS: Xin lưu ý rằng tôi đã thấy câu hỏi này . Đó là một cái gì đó hoàn toàn khác với những gì tôi đang hỏi ở đây. Vì vậy, xin vui lòng không đề cập trùng lặp .

Thứ mang lại cho XML sức mạnh và rất nhiều sự phức tạp của nó là nội dung hỗn hợp. Những thứ như thế này:

<p>A <b>fine</b> mess we're in!</p>

Thậm chí đừng cố gắng làm điều đó trong JSON hoặc thao tác nó trong các ngôn ngữ lập trình thông thường. Họ không được thiết kế cho công việc.

Loại câu hỏi này thường xuất phát từ những người quên rằng M trong XML là viết tắt của đánh dấu. Đó là một cách lấy văn bản đơn giản và thêm đánh dấu để tạo văn bản có cấu trúc. Nó cũng khá tiện lợi cho dữ liệu lỗi thời, nhưng đó không phải là những gì nó được thiết kế cho hoặc nơi sức mạnh chính của nó nằm. Có rất nhiều cách xử lý dữ liệu đơn giản và JSON là một trong số đó.

Sự khác biệt chính, tôi nghĩ, là ở chỗ, XML được thiết kế để tự giải thích với dtd của nó và mọi thứ.

Với JSON, bạn phải thừa nhận rất nhiều về dữ liệu bạn đang nhận.

Một bản dịch theo nghĩa đen sang JSON thường ít cô đọng và ít rõ ràng hơn. Xem xét:

<foo>
   <x:bar x:prop1="g">
      <quuz />
   </bar>
</foo>

Đại diện JSON hiệu quả nhất mà tôi đã thấy về điều này:

{"localName":"foo",
 "children": // you need to have a special array to hold all children
 [
    {"localName": "bar",
     "namespace": "x"
        // once again, to ensure that there are no collisions,
        // attributes should be brought out into their own JSON structure 
        "attributes":[
            {"localName":"prop1",
             "namespace":"x",
             "value":"g"}
        ],
         "children":[
             {"name":"quux"}
         ]
     }
 ]}

Bây giờ, hãy tưởng tượng rằng cho toàn bộ tệp XML. Tôi không nói rằng JSON không có vị trí của nó, nhưng không nên loại trừ XML.

JSON và XML đều là cách định dạng dữ liệu. Cả hai đều có khả năng thực hiện nó hoàn hảo, vậy JSON có thể làm mọi thứ XML không? Đúng.

Nhưng ..... Một câu hỏi phù hợp hơn có thể không phải là những gì XML / JSON có thể làm, mà là, bạn có thể làm gì với XML / JSON.

Có một số điều bạn có thể làm với XML mà tôi không nghĩ là bạn có thể làm với JSON, chẳng hạn như dịch bằng XLST, tìm kiếm bằng XPath và xác thực bằng các lược đồ. Tất cả rất, rất hữu ích.

Có rất nhiều chức năng sử dụng XSLT có thể không khả dụng với JSON. Vì vậy, nếu chúng không tương đương về chức năng, chúng không thể thay thế nhau.

Thực tế là, chúng ta sẽ phải sống với cả hai trong một thời gian dài và việc trở thành một người khổng lồ JSON là "bị coi là có hại".

JSON là khá mới và các hệ thống kế thừa sẽ không hỗ trợ nó. Nâng cấp hệ thống kế thừa là nhanh chóng và giới thiệu các lỗi. JSON sẽ không thay thế XML bất cứ lúc nào trong tương lai gần.

Tôi muốn nói rằng cwallenpoole là một điểm tuyệt vời. Mặc dù hầu hết XML có thể được dịch sang JSON, nhưng liệu làm như vậy có tốt hơn cho nó hay không là một điểm riêng biệt.

JSON cho vay các cấu trúc dữ liệu ít nhất cũng như XML và có thể tốt hơn, nhưng XML đọc tự nhiên hơn nhiều so với JSON khi đánh dấu các tài liệu văn bản, trong đó các thẻ được sử dụng trong một luồng văn bản lớn hơn thay vì chỉ đơn giản là một cách để phân định thứ bậc của các lĩnh vực.

Mặc dù HTML 5 có thể có trình phân tích cú pháp riêng, nhưng vẫn để lại các ứng dụng như DocBook.

Nó phụ thuộc vào tên miền. Về mặt dịch vụ web? Chắc chắn rồi. Thật đáng xấu hổ khi các nhà cung cấp vẫn đang thúc đẩy SOAP cho khách hàng của họ. REST + JSON mọi cách.

Bây giờ, khi bạn đang nói về dữ liệu phức tạp, có cấu trúc với thông tin kiểu như Docbook hoặc cách triển khai khác? Đó là một miền thích hợp cho XML.

Tại sao lại giới hạn bản thân với JSON khi YAML là một siêu tập hợp và biểu cảm hơn và do đó mạnh hơn XML hoặc JSON.

Điều đó nói rằng, nếu bạn sử dụng các khung tuần tự hóa chính xác, bạn sẽ có thể tuần tự hóa và hủy tuần tự hóa tất cả các định dạng được đề cập ở trên với một vài dòng mã đơn giản.

Thật tệ khi bạn cố gắng mô hình hóa hai đối tượng này trong JSON:

<customer><name>John Doe</name></customer>
<employee><name>John Doe</name</employee>

Sử dụng JSON như đã quen với 99% trường hợp người ta bị lạc với:

{ name: "John Doe" } 

Và bây giờ bạn phải thêm một số cấu trúc meta và tất cả vẻ đẹp của JSON sẽ biến mất trong khi bạn còn lại những nhược điểm.

Tôi không biết liệu một phương tiện như vậy có tồn tại cho JSON hay không, nhưng trong .NET ít nhất bạn có thể xác thực XML dựa trên một lược đồ đã cho. Đó là một lợi thế có giá trị của XML trong mắt tôi.