W3C home > Mailing lists > Public > public-exi@w3.org > August 2006

XBIS format

From: Dennis Sosnoski <dms@sosnoski.com>
Date: Thu, 17 Aug 2006 21:20:50 +1200
Message-ID: <44E434F2.8040605@sosnoski.com>
To: public-exi@w3.org


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

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

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 

5.14 Human Language Neutral

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

5.18 No Arbitrary Limits
Yes, all values extensible.

5.19 Platform Neutrality

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

5.29 Support for Error Correction
Not a consideration, and minimal support.

5.30 Transport Independence

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

6.4 Single Conformance Class

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:11 UTC