RE: ASN.1 is an XML Schema Language (How many encodings?)
Claude L Bullard wrote: >Fewer encodings is better. Without question this is true -- as long as you accept: We should have no fewer encodings than necessary... The question is: How many are necessary and what should they/it be? Of course, answering those two questions could take a very long time... > Yet more encodings have costs so communities of interest > should beware arguments that come down to lossless transcoding. You are absolutely right. Perhaps we should state a rule: "We should have no *more* encodings than necessary..." (the inverse of above...) There are few things more frustrating than having to devote valuable engineering time to supporting some "cool new" format that offers absolutely no real benefit over what we were using already but just happens to be popular with the customer/user/devloper community this week. This is one of the reasons that I really like the idea behind ASN.1 and abstract syntaxes in general. As long as my structures are defined in an abstract manner, what I need to support some random new format is simply a new encoder/decoder which should use the same APIs as the stuff I had before. Given a nicely modular system like this I'm shielded from much of the expense of dealing with the "fad of the week/year" when it comes to encoding. However, this doesn't mean that I think we should switch encodings casually. In fact, I couldn't feel more strongly that we should minimize the number of encodings that we use. i.e. We should have no more and no fewer than necessary. Less means we can't accomplish important goals, more means that we're wasting our time. After almost 30 years in the business I'm really tired of seeing coder's time and lives wasted by supporting stuff that offers no real advantage over what we already had. This is one reason why I support PER instead of one of the "binary flavors of the month." We've already got PER and we've got tools that handle it. Unless something is massively better, there is no reason to retool or invent something new. [Flame Alert...] I am really [expletive deleted] by the evidence that some of the people who are proposing new binary formats have not had the decency or responsibility to research what already existed before taking all our time with their proposals... If you are going to propose something new, then you have a responsibility to study the past carefully and explain in detail why your solution is better than what came before. Some of the "binary XML" proposals look like simple reinventions of BER and could only have been put forward by someone who wasn't aware of BER -- thus, someone who simply didn't spend enough time researching the problem domain before hassling us all with their silly proposals. Reviewing them has been an absolute waste of everyone's time. We have BER. We don't need a "new BER." bob wyman
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format