RE: Non-XML binary formats.

Robin Berjon wrote:
> Your tone here makes me wonder...
	If there is some emotion in my tone it is rooted in the frustration
that comes from watching the glacial pace of the XBC process while knowing
that there are at least some of us that need to build systems TODAY that
have the efficiencies and advantages provided by binary formats. Had it not
been for the fact that all of the requirements that are so far identified by
the XBC group have been the subject of constant scrutiny, debate and
resolution for over 20 years, then I would be much more patient. However,
the simple fact is that the ASN.1 group has been dealing with all of these
issues for years and has produced a system that can address the vast
majority of the needs identified. 
	What the XBC process is doing is creating FUD (Fear Uncertainty and
Doubt) that prevents us from deploying standards-based binary solutions
today. Any proposal for a binary based system today is routinely rejected
not on technical grounds but rather with the statement that "We should wait
to see what W3C says." Thus, we are forced to accept higher bandwidth costs
then would otherwise be necessary, higher processing costs, etc. The glacial
pace of the XBC process is costing us money and preventing us from
satisfying user requirements for responsive, efficient systems. These costs
simply do not seem justified given that ASN.1 exists, is a standard, and
there are no recognized standard alternatives that address the same range of
requirements that ASN.1 does. 
	We have already been forced to accept the cost of waiting for and
now dealing with XML Schema -- even though its mapping to a subset of ASN.1
has shown that the effort contributed little of new value -- other than a
ridiculously verbose and difficult to read syntax whose only redeeming
quality seems to be its blessing by the W3C. Now, we're being slowed down
again as the W3C insists once again that the industry can move no faster
then the W3C dictates.
	Frankly, I'm tired of waiting and I'm terribly afraid that W3C is
going to spend years generating FUD on this issue and then force us to
accept some "new, cool" standard which once again offers little, if any,
advance over what we already have. So far, I've seen no evidence in any of
the various formats presented in this list or at the various workshops that
there exists a candidate format that would be vastly superior to what ASN.1
has already defined. If there were even a hint of such a format, this
interminable waiting would be much more tolerable.
	My interest here is not academic or casual. I work every day with
systems that push the envelope of XML processing and systems that are
identified in the XBC Use Cases document. For instance, XMPP compression,
Content-Based Publish and Subscribe, Web Services, Embedding External Data
in XML, Electronic Documents, Intra/Inter Business Communications -- these
are all use cases that define my every day life. I'm working with this stuff
TODAY and it has only been possible to achieve the throughput that we do by
converting all the XML to ASN.1 prior to processing it.[1] Our system simply
wouldn't work if we were forced to use text-based XML. This is reality --
not some problem that will arise in the future.
 
> I regularly hear talks about ASN.2 doing to ASN.1 what XML did to SGML. 
> I'd be curious to hear what the current thinking on that is.
	I've been following ASN.1 since its birth when I was at Digital
since we were one of the first, if not the first, company to convert from
"NBS format" to ASN.1 in our email products. I've never heard of anyone
responsible talking seriously about "ASN.2". The term "ASN.2" usually only
appears in discussions of why "ASN.2" wouldn't make sense. We are no more
likely to have an ASN.2 then we are to have PL/2... However, that is not to
say that ASN.1 does not evolve and address new needs. It has done so
regularly over the years. What it doesn't do, however, is change its name.

> I'm not saying that ASN.1 is the Cobol of data frameworks, but simply
> that "already could do for n years" is a non-argument.
	It certainly *should* be accepted as an argument unless there is
some serious counter argument. Why invent something new if the old thing
does the job and does it well? If you compare ASN.1 to COBOL and FORTRAN,
you have to remember that they were both defined in the 1950's yet we've
learned a great deal about computer programming since then. On the other
hand, ASN.1 was defined in the 1980's -- after we had learned much more. The
pace of development of language concepts was much greater between 1950 and
1980 then it has been since 1980. Thus, while ASN.1 may have some age to it,
it still incorporates much of what we consider to be "modern" ideas today.
i.e. modularization, etc. Additionally, ASN.1 has been going through active
refinement and enhancement ever since it was first defined. Comparing it to
COBOL and FORTRAN is simply not fair.

		bob wyman

[1] http://bobwyman.pubsub.com/main/2004/02/xml_asn1_and_th.html

Received on Thursday, 2 December 2004 10:12:57 UTC