- From: Dennis Sosnoski <dms@sosnoski.com>
- Date: Thu, 17 Aug 2006 21:20:50 +1200
- To: public-exi@w3.org
Hi EXI, I just looked in on the work you've been doing, and wanted to point out XBIS to anyone interested: http://www.xbis.org XBIS predated the formation of the group and was one of the formats represented by a paper for the original W3C Workshop on Binary Interchange of XML Information Item Sets. I realize this is late for XBIS to be considered as a candidate for your particular WG, but you may still find some of the ideas interesting. In regard to the properties listed in the XBS Properties Note (all figures based on published XBIS comparisons using open source Java implementation and test code): 4.1 Processing Efficiency 1. Serialization speed - roughly 20% faster than text, on average, writing to in-memory stream destination; much better for sequence of small documents using the same element and attribute set (such as typical SOAP) 2. Parsing speed - generally about 4x fast SAX text parser speed, with SAX output adapter 3. Data binding - not addressed directly, but easily adapted (though XBIS is based on a text transformation, not on actual binary data values) 4.2 Small Footprint The one implementation to date is roughly equivalent to one of the smaller SAX parsers 4.3 Space Efficiency Probably about equivalent to a standard parser 5.1 Accelerated sequential access Not addressed by XBIS testing, though the format should be at least several times faster than text 5.2 Compactness Roughly half the size of plain text documents 5.3 Content Type Management XBIS is intented to be used as a content coding 5.4 Deltas Not implemented by XBIS code, but possible with extensions to the format 5.5 Directly Readable and Writable Yes 5.6 Efficient Update Not implemented by XBIS code, but possible 5.7 Embedding Support Not implemented by XBIS code, but possible with extensions to the format 5.8 Encryptable Not implemented by XBIS code, but possible with extensions to the format 5.9 Explicit Typing XBIS is a text transformation for XML documents, so does not support this. 5.10 Extension Points Extension points available within the format, by using added node types. 5.11 Format Version Identification Yes 5.12 Fragmentable Yes, in the sense of elements or lists of elements being treated as a unit. The format itself does not support immediately extractable fragments. 5.13 Generality XBIS is designed to support all of XML, with retention of all information necessary to preserve the canonical form of the original document. 5.14 Human Language Neutral Yes 5.15 Human Readable and Editable Not a design concern, and generally not possible with XBIS. It does maintain order and position of information items, but does not keep element names inline after their initial definition. 5.16 Integratable into XML Stack Yes. In particular, it supports preserving canonicalization with important implications for signatures and such. 5.17 Localized Changes Yes. 5.18 No Arbitrary Limits Yes, all values extensible. 5.19 Platform Neutrality Yes. 5.20 Random Access No, though indexing should be fast. 5.21 Robustness Somewhat, but generally not an intent of the format. 5.22 Roundtrip Support Generally lossless in terms of XML processing (i.e., ignoring issues such as whitespace between attributes, line endings, etc.), but may have issues with things like redundant namespace declarations in the original document. XBIS is intended to preserve the canonical form of the document rather than the raw text. 5.23 Schema Extensions and Deviations Schema unaware. 5.24 Schema Instance Change Resilience Schema unaware. 5.25. Self Contained Yes, though XBIS optionally allows streaming of documents using common formats for improved efficiency (basically allowing the element and attribute names to be reused once defined). 5.26 Signable Easily signable, and defining a canonical form for the XBIS representation would be easier than for text XML. It would be easy to modify the code to create this canonical representation directly on write, with only a small added overhead. Partial signatures would also be easy to add. XBIS is more intended to be used with documents that use standard XML Signature, though. 5.27 Specialized codecs Not supported, though easy to add (just define another node type, which identifies a codec for the following data). 5.28 Streamable Yes. 5.29 Support for Error Correction Not a consideration, and minimal support. 5.30 Transport Independence Yes. 6.1 Forward Compatibility Yes, to the extent it's possible to foresee. 6.2 Implementation Cost I'd consider it moderate. 6.3 Royalty Free Yes. 6.4 Single Conformance Class Yes. 6.5 Widespread Adoption About as wide as any binary formats to date. - Dennis -- Dennis M. Sosnoski SOA, Web Services, and XML Training and Consulting http://www.sosnoski.com - http://www.sosnoski.co.nz Seattle, WA +1-425-296-6194 - Wellington, NZ +64-4-298-6117
Received on Thursday, 17 August 2006 09:21:09 UTC