What about a thread on articles describing or reporting on Binary XML?
I'll post a few I know off-hand.
I did a two-part series on IBM developerWorks last year discussing XML Transport Performance: [url]http://www-128.ibm.com/developerworks/xml/library/x-trans1.html[/url] and [url]http://www-128.ibm.com/developerworks/xml/library/x-trans2/index.html[/url]. Once you have full SAX support for FI it'll be interesting to see how the performance compares with XBIS ([url]http://www.xbis.org[/url]).
Yep, I agree. And looking deep into what causes what type of performance will be useful too.
Rick Jelliffe's blog on Fast Infoset:
is interesting and positive.
By way of Rick there is a less positive view:
which contains a mis-conception about Fast Infoset and its used of ASN.1. Fast Infoset does not use the ASN.1 Packed Encoding Rules (PER).
An optimal encoding (size and processing) has been specifically designed that balances a number of use-cases (e.g. retain self-description/structure, streaming, efficient support for numerical data, extensible encodings).
ASN.1 is used to formally specify the abstact values, that represent information items, and the encoding of the values. The encoding is formally specified using the Encoding Control Notation. However, the specification also describes the encoding in English language and contains examples.
The source code can be viewed here:
The SAX serializer/parser (albeit incomplete, but still functional, at the moment) it is not that complicated.
A better connection between XML and PER is what we term Fast Schema, or the mapping of W3C XML schema to ASN.1 schema (an ITU-T/ISO standard). This produces optimal encodings (very small and fast to process) but the self-describing information and structure is not encoded.
It is swings and roundabouts. Some properties of XML are traded for some properties that produce better size and processing characteristics (e.g. human readability or self-description). In general the more properties you trade the more optimal you can get.
I think Fast Infoset has a good balance in terms of size and processing. It looses the human readability property of XML but retains the self-descriptive property.
An article by Michael S. Mimoso on SearchWebServices, on Nov 22, 2004.
From the article...
"Leventhal made a lot of people think twice about binary XML during a session at the conference, where he explained there are currently 19 binary XML formats in use today across many industries -- and those industries are going to continue to use binary XML whether or not there's a standard version. In this interview, he explained the potential impact of binary XML on the market and enterprises, and the need for a single standardized format."
I think that the core argument, that these industries will continue to use binary XML formats because there is a market need for it, is solid. Whether it is possible to have a single format satisfy all the needs is, I think, a different question. For example, there could be a binary encoding that is targetted at efficient updates of partial portions of XML documents. Does we need to impose that requirement on *the* standard? My inclination is not.
The approach we have taken with Fast Infoset is to address the sweet spot of binary XML encoding. I think the standard succeeds. Fast WebServices is more specialized - and more efficient in most cases - but harder to use; but Fast Infoset is easy to implement and integrate and quite efficient; and it has extra flexibility with external vocabularies and customizable encodings. I believe we will see a substantial following on Fast Infoset, and we hope that the project at Java.Net will help its adoption.
Martin LaMonica wrote an article this week in C|Net.
A pretty reasonable article, imho, and it mentions the FI@Java.Net project directly, which is nice... :-).
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.