EXI (trao đổi XML hiệu quả) đang đến ... Các API XML đã sẵn sàng chưa?

Question

EXI của W3 (trao đổi XML hiệu quả) sẽ được chuẩn hóa. Nó tự xưng là "tiêu chuẩn nhị phân cuối cùng".

Đây là tiêu chuẩn để lưu trữ dữ liệu XML được tối ưu hóa để xử lý và lưu trữ , được đi kèm với lược đồ XML (làm cho dữ liệu được nhập mạnh mẽ và có cấu trúc mạnh). Vâng, có rất nhiều lợi ích được tuyên bố là . Tôi đã bị ấn tượng nhất bởi việc xử lý và đo lường hiệu quả bộ nhớ .

Tôi tự hỏi, điều gì sẽ xảy ra với tất cả các API XML được thiết lập?

Có đoạn này liên quan đến câu hỏi của tôi:

4,2 hiện API Xử lý XML

Như EXI là một mã hóa của Infoset XML, một thực hiện EXI có thể hỗ trợ bất kỳ XML thường được sử dụng API để xử lý XML, vì vậy EXI không có tác động ngay lập tức đến các API XML hiện có. Tuy nhiên, việc sử dụng một API XML hiện có cũng yêu cầu tất cả các tên và văn bản xuất hiện trong tài liệu EXI được chuyển đổi thành các chuỗi. Trong tương lai, hiệu quả hơn có thể đạt được nếu các lớp cao hơn có thể trực tiếp sử dụng các dữ liệu này như các giá trị đã nhập xuất hiện trong tài liệu EXI. Ví dụ, nếu một lớp cao hơn cần dữ liệu đã nhập, đi qua biểu mẫu chuỗi của nó có thể tạo ra một hình phạt hiệu suất, do đó một API mở rộng hỗ trợ dữ liệu đã nhập trực tiếp có thể cải thiện hiệu suất khi được sử dụng với EXI.

từ: http://www.w3.org/TR/exi-impacts/

tôi hiểu nó như sau: "?! Sử dụng EXI với các API hiện Không đạt được hiệu suất (Trừ khi bạn viết lại cho họ tất cả)"

Hãy lấy hệ sinh thái Java làm ví dụ:

Chúng tôi có nhiều API XML trong JDK mới nhất 6 (Với mỗi bản phát hành JDK chính, ngày càng nhiều người trong số họ được thêm vào.) Theo như tôi có thể đánh giá, hầu hết (nếu không phải tất cả) trong số họ đang sử dụng hoặc cây DOM trong bộ nhớ hoặc đại diện ("văn bản") được nối tiếp để chuyển đổi/xử lý/xác thực/... dữ liệu XML.

Các bạn nghĩ gì, điều gì sẽ xảy ra với các API này khi giới thiệu EXI?

Cảm ơn tất cả vì ý kiến ​​của bạn.

Đối với những người không biết EXI: http://www.w3.org/XML/EXI/

Answer 1

Bạn không cần bất kỳ API mới nào để có được hiệu suất hoạt động của EXI. Tất cả các phép đo thử nghiệm và hiệu suất của EXI mà W3C đã thực hiện đều sử dụng các API SAX chuẩn được tích hợp trong JDK. Để có các bài kiểm tra mới nhất, hãy xem http://www.w3.org/TR/exi-evaluation/#processing-results. Phân tích EXI nhanh hơn trung bình 14,5 lần so với XML trong các thử nghiệm này mà không có bất kỳ API đặc biệt nào.

Một ngày, nếu mọi người nghĩ rằng nó đáng giá, chúng tôi có thể thấy một số API XML đã nhập xuất hiện. Nếu và khi điều đó xảy ra, bạn sẽ nhận được hiệu suất tốt hơn từ EXI. Tuy nhiên, điều này là không cần thiết để có được hiệu suất tuyệt vời như được báo cáo bởi W3C.

Answer 2

Tôi muốn đích thân thay vì không sử dụng EXI ở tất cả. Nó có vẻ như nó lấy tất cả những điều khó khăn, xấu về XML, và nhồi nhét chúng vào một định dạng nhị phân, mà về cơ bản loại bỏ ân sủng tiết kiệm của XML (định dạng văn bản thuần túy).

Dường như xu hướng chung của ngành đang hướng tới các mô hình chuyển dữ liệu nhẹ hơn (ví dụ HTTP REST) ​​và di chuyển ra khỏi các mô hình có trọng lượng nặng như SOAP. Cá nhân, tôi không phải là siêu vui mừng về ý tưởng của XML nhị phân.

Bất kỳ nội dung nào được cho là "tiêu chuẩn nhị phân cuối cùng" có thể là sai.

Answer 3

Hãy xem EXI là "GZIP tốt hơn cho XML". FYI, nó không ảnh hưởng đến các API vì bạn vẫn có thể sử dụng tất cả chúng (DOM, SAX, StAX, JAXB ...). Chỉ có điều đó để có được EXI, bạn phải có được một nhà viết nhạc viết cho nó hoặc một người viết luồng đọc nó.

Cách hiệu quả nhất để thực hiện EXI là STAX. Nhưng đúng là API mới có thể phát sinh do EXI. Nhưng ai nói DOM có hiệu quả và được thiết kế tốt cho các ngôn ngữ hiện đại ;-)

Nếu bạn đang xử lý các tệp XML lớn (tôi có một vài trong số đó là vài trăm MB), bạn biết rõ tại sao bạn cần EXI: của không gian, tiết kiệm rất nhiều bộ nhớ và thời gian xử lý.

Điều này không khác gì so với mục đích Mã hóa nội dung HTTP: bạn không bắt buộc phải sử dụng nó, đơn giản là nếu cả hai bên hiểu nó, đó là một cách hiệu quả để thực hiện trao đổi. Bằng cách này, EXI sẽ trở thành cách ưa thích hơn để nội dung-encore bất kỳ XML qua HTTP IMHO vì SOAP sưng lên ;-) Ngay sau khi EXI giải quyết trên trình duyệt, nó cũng có thể có lợi cho bất kỳ người dùng cuối: chuyển nhanh hơn, nhanh hơn phân tích = trải nghiệm tốt nhất từ ​​trước đến nay cho cùng một máy!

EXI không từ chối biểu diễn chuỗi, chỉ làm cho nó hơi khác một chút. Oh và bằng cách này, khi thực hiện UTF (nghĩ mặc định là UTF8), bạn đã sử dụng "mã hóa nén" cho điểm mã unicode 32 bit ... điều này có nghĩa là trên dữ liệu dây không giống như dữ liệu thực đã ;-)

Answer 4

Vấn đề với EXI là nó cần phải được tóm tắt từ mã ứng dụng của bạn. Tôi làm việc trên một sản phẩm phần mềm trung gian mà bản chất XML có thể đọc được của con người là chìa khóa trong các khía cạnh nhất định (ghi nhật ký, tìm lỗi, vv) nhưng có thể hy sinh ở các khu vực khác (giao tiếp giữa các ứng dụng nội bộ để hạn chế tải I/O).

Hiện tại, chúng tôi sử dụng SOAP để liên lạc giữa hoặc sở hữu ứng dụng web của khách hàng, trung gian và nhà cung cấp. Tôi muốn thay thế điều này bằng EXI, trong khi vẫn giữ được XML có thể đọc được ở các khu vực khác. Để thay thế truyền thông SOAP với EXI tôi hoặc là cần phải:

1. Chờ cho đến khi EXI đã được đưa vào ngăn xếp SOAP hiện có (Axis/SAAJ), hoặc
2. Thay Axis/SAAJ SOAP client/triển khai cung cấp hiện tại của tôi với giao thức SOAP-ish của riêng tôi ở trên cùng của EXI

So sánh giữa JSON và EXI là công bằng, nhưng trường hợp sử dụng cho hai trường này là khác nhau. Không có chuẩn cho siêu dữ liệu cho JSON, trong khi có XML-Schema cho XML. Với XML, có một số cơ quan tiêu chuẩn xác định các lược đồ để trao đổi dữ liệu cho các ngành cụ thể. Ngoài ra còn có một loạt các giao thức/tiêu chuẩn được xây dựng trên đầu trang của XML, chẳng hạn như SOAP, XML-Signature, XML-Encryption, WS-Security, SAML, vv Điều này không tồn tại cho JSON.

Do đó, XML là một lựa chọn tốt hơn cho trao đổi thông điệp B2B và các trường hợp khác mà bạn cần tích hợp với hệ thống bên ngoài bằng các tiêu chuẩn ngành. EXI có thể mang lại một số lợi ích của JSON vào thế giới này, nhưng nó cần phải được tích hợp vào các API XML hiện có trước khi có thể áp dụng rộng rãi.

Answer 5

Tôi đang xử lý EXI ngay bây giờ.

Không có công cụ phổ biến nào để xử lý EXI. Một khi bạn nhận được vào ruột của EXI, bạn nhận ra có một loạt các dấu phân cách không cần thiết trong luồng nhị phân hoàn toàn và hoàn toàn không cần thiết với một lược đồ. Một số của nó là hài hước.

Bạn nghĩ điều sau đây sẽ được mã hóa như thế nào trong EXI nếu cả hai giá trị được chỉ định?

<xs:complexType name="example"> 
    <xs:sequence> 
    <xs:element name="bool1" type="xs:boolean" minOccurs="0" /> 
    <xs:element name="bool2" type="xs:boolean" minOccurs="0" /> 
    </xs:sequence> 
</xs:complexType> 

Bạn có nghĩ rằng nó có thể là tối đa 4 bit không? 1 bit để chỉ ra nếu bool1 được xác định, và rằng giá trị của bool1, theo sau là một bit khác để chỉ ra nếu bool2 được xác định, sau đó giá trị của bool2?

Tốt golly no!

Vâng, hãy để tôi nói cho bạn biết nam và nữ! Đây là cách nó thực sự được mã hóa

+---- A value of 0 means this element (bool1) is not specified, 
|  1 indicates it is specified 
|+--- A value of x means this element is undefined, 
||  0 means the bool is set to false, 1 is set to true 
||+-- A value of 0 means this element (bool2) is not specified, 
|||  1 indicates it is specified 
|||+- A value of x means this element is undefined 
|||| 0 means the bool is set to false, 1 is set to true 
|||| 
0x0x 4 0100   # neither bools are specified 
0x10 8 00100000  # bool1 is not specified, bool2 is set to false 
0x11 8 00101000  # bool1 is not specified, bool2 is set to true 
100x 9 000000010  # bool1 is set to false, bool2 is not specified 
110x 9 000010010  # bool1 is set to true, bool2 is not specified 

1010 13 0000000000000 # bool1 is set to false, bool2 is set to false 
1011 13 0000000001000 # bool1 is set to false, bool2 is set to true 
1110 13 0000100000000 # bool1 is set to true, bool2 is set to false 
1111 13 0000100001000 # bool1 is set to true, bool2 is set to true 
     ^  ^
     +-encoding--+ 

Which can be represented with this tree 

    0-0-0-0-0-0-0-0-0-0-0-0-0 (1010) 
    \ \ \  \ \ 
    | | |  | 1-0-0-0 (1011) 
    | | |  | 
    | | |  1-0 (100x) 
    | | | 
    | | 1-0-0-0-0-0-0-0-0 (1110) 
    | |  \ \ 
    | |   | 1-0-0-0 (1111) 
    | |   | 
    | |   1-0 (110x) 
    | | 
    | 1-0-0-0-0-0 (0x10) 
    | \ 
    |  1-0-0-0 (0x11) 
    | 
    1-0-0 (0x0x) 

Tối thiểu 4 bit, tối thiểu để không xác định. Bây giờ tôi là một chút không công bằng, bởi vì tôi bao gồm các dấu phân cách - dấu phân cách hoàn toàn không cần thiết.

Tôi hiểu cách hoạt động của tính năng này ngay bây giờ. Dưới đây là thông số kỹ thuật:

https://www.w3.org/TR/exi/

Vui vẻ đọc điều đó! Đó là một TUYỆT VỜI TUYỆT VỜI CHO TÔI !!!! @@ ##! @

Bây giờ đây chỉ là một lược đồ, và đặc tả EXI đặc biệt nói rằng bạn vẫn có thể mã hóa XML KHÔNG phù hợp với lược đồ . Đó là vui nhộn bởi vì đây là nghĩa vụ phải được cho các thiết bị web nhỏ nhỏ. Bạn làm gì với dữ liệu không mong muốn mà bạn không có quy định để xử lý trong một thiết bị nhúng?

Tại sao, bạn chỉ cần chết tất nhiên. Không có sự phục hồi cho một cái gì đó bạn không mong đợi. Nó không giống như những thứ này có một màn hình, tôi may mắn nếu tôi có thể đăng nhập vào nó thông qua một cổng nối tiếp.

Tôi đã sử dụng 4 trình tạo/trình phân tích cú pháp/trình tạo XML khác nhau XSD. 3 trong số họ bị nghẹt thở trên Schema tôi phải sử dụng. Dữ liệu marshaling cho C và C++ (nhớ điều này là dành cho hệ thống EMBEDDED với bộ nhớ rất ít và sức mạnh CPU) là khủng khiếp.

XSD mô tả về cơ bản cấu trúc hoặc kiến ​​trúc lớp và không có một công cụ duy nhất tôi có thể tìm thấy sẽ chỉ tạo các lớp. Ví dụ XSD mà tôi đưa ra ở trên nên tạo một cấu trúc với 4 bool, 2 bools là các giá trị và 2 bool cho biết nếu chúng được xác định.

Nhưng điều đó có tồn tại không? Vâng heck không.

Tôi thích XML, để mô tả tài liệu. Thực sự tôi làm - nhưng đây là những gì tôi ghét về XML - cho một tiêu chuẩn được chấp nhận rộng rãi, các công cụ có sẵn cho nó là hoàn toàn khủng khiếp. Chỉ cần đọc một lược đồ là một việc khó làm khi nó trải rộng trên nhiều không gian tên và tài liệu.

rant Rant, hết sức giận dữ HUF

Lý do duy nhất chúng ta đang sử dụng đây là một số ủy ban tiêu chuẩn khẳng định sau khi nó. Những gì nó được thực hiện được tạo ra một độc quyền cho một nhóm nhỏ các công ty đã thực hiện điều này, đó là mục đích duy nhất.

EXI không phải là một tiêu chuẩn được chấp nhận rộng rãi, XML là một trình đóng gói kém cho dữ liệu số, và đó là một nỗi đau để thực hiện nó và không có công cụ phong nha cho nó. EXIP đang ở phiên bản 5.0 - bất cứ thứ gì hoạt động đó là mã nguồn mở đều có trong Java - ít nhất tôi có điều đó.

Đối với lĩnh vực hoạt động của mình, EXI chỉ là một quyết định thiết kế tồi. Tôi đã làm việc trên tấn giao thức truyền thông trên các hệ thống nhúng khác nhau. Tôi đã làm việc trên DOCSIS, tất cả các modem cáp hiện đại đều sử dụng - chúng sử dụng giao thức Type/Length/Value đơn giản và có thể mở rộng với các điều khoản để xử lý các loại không được công nhận - đó là lý do tại sao Độ dài luôn được bao gồm. Thật đơn giản, phải mất hàng ngày để thực hiện toàn bộ ngăn xếp.

EXI rất khó để viết mã, không có bộ vi xử lý phù hợp cho nó, và tất cả các bộ vi xử lý tôi thấy rằng thực sự hoạt động tốt với nó, chỉ cần chuyển đổi từ EXI < -> XML - hoàn toàn vô dụng.

Tôi đã sử dụng để viết trình phân tích cú pháp XSD của riêng mình, có nghĩa là tôi phải hiểu ít nhất toàn bộ đặc tả XML cho các phần của thiết kế này sử dụng nó - và đó là mở rộng. Tôi sẽ mất 2 tuần để làm với bất kỳ thông số hợp lý nào, đưa tôi đi 10. Không ai trong thế giới của tôi sẽ sử dụng nó trừ khi nó bị đẩy xuống cổ họng của họ và họ không nên, đó là một cái chốt hình vuông cho một lỗ tròn.