Re: Non-XML binary formats.

Bob Wyman wrote:

>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. 
>  
>
There have been plenty of people needing to build systems using binary 
formats since the dawn of communications.  The XBC process did not stop 
them then, and it's not stopping them now.  Rushing the process of the 
XBC will do nothing but create a new standard that will be incomplete 
and difficult to use and implement (ie. see WS-* for examples).  Good 
standards are worth the wait.

I've already pointed out to you my requirements which ASN.1 does not 
address.  And you yourself say that ASN.1 will not address some of the 
other needs.  Maybe it's time for you to pull your head out of the ASN.1 
sand, and start looking around to see what else is out there.  That is 
exactly what I'm trying to do.  Ask some questions and stop being 
ignorant of other solutions available on the market.  It will give you a 
stronger point from which to argue the ASN.1 case,  or discover that 
ASN.1 isn't the solution fit for every purpose.  If you already do know 
the other standards out there, start saying exactly where and why they 
don't work.  Your arguments so far having been little more than hot air.

>	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. 
>  
>
As a solutions provider, surely your response is.  "Standards take a 
long time. If you want this project to succeed, then it's best we pick a 
solution that works now."  If the companies you deal with are willing to 
wait, then their need for a solution obviously isn't that great.  The 
other point you can make is that ASN.1 is a solution for now.  Design 
your systems so that another solution can be put in place later.

I don't see this FUD you're talking about anywhere.  Can you detail it 
in any more detail?  Or is it just the fact you haven't got an ASN.1 
based standard right now, and you're not happy about it?

>	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.
>  
>
I agree that XML Schema wasn't the best solution they could have come up 
with.  However, I believe they still made the right choice of creating 
their own standard.  I also think the W3C shouldn't tie the XBC to 
ASN.1.  If future changes are required then it ties the whole W3C to the 
ASN.1 committee.  There is enough red tape and politics in standards as 
it is.  Tieing two large committees together would just add more warts 
and humps to the committee designed standard.  Just because *you* think 
that ASN.1 is the best solution doesn't make it a good fit.   I don't 
think the ASN.1 solution is right for XML, and there are obviously 
others on the list who feel the same.

>	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.
>  
>
More FUD.  I'm not so sure that binary description languages are ever 
going to be "new" or "cool".   However there are some rather interesting 
new concepts being developed in the area.  I know for a fact that you 
haven't given my "vastly superior" and "new, cool" format any more than 
a cursory glance.  If you had, you might asked questions like "Your web 
site claims that Argot is self describing.  What do you mean?", or "What 
benefits are there to having the description format in binary?", maybe 
even, "How would you convert XML into Argot?"  As a starting point have 
a look at this page http://www.einet.com.au/kb.x?T=18   Look at each 
definition and see that each definition is defined by other definitions 
on that page.  Then realise that you could introduce new ways to 
describe data without breaking the dictionary.  Think about what that 
implies.

>	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.
>  
>
Exactly why many of us are here.

> 
>  
>
>>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.
>  
>
Maybe it's time that ASN.2 was created.  Clean up the standards.  Move 
things around.  Break compatibilitiy.  A 21st birthday spring cleaning?

Regards,
David Ryan.
www.einet.com.au

Received on Sunday, 5 December 2004 23:44:16 UTC