[
Lists Home |
Date Index |
Thread Index
]
Reinvention and not doing the homework are facts of
life on the web. Weirdly enough, one of the reasons
for the web was to make that very easy to do and it
usually is. I do remember spending weeks at a time
in the university technical library finding out things
that I can now find out in seconds, but oh well.
What would be interesting is to hear reasons for
having multiple encodings. While generalized binaries
for XML have been hotly debated (and they do exist
as Robin Berjon can attest to), it has been said that
a generalized binary doesn't do enough to make it
worth having for apps that really need one. X3D
will have a binary without a doubt and companies
are bidding that work. I shall be interested to
see if a specialized binary or a generalized binary
is selected. Free bolt-in decoders will be a factor.
But given your years of experience, why are multiple
encodings ever necessary excepting the binary which
I put in a class of its own?
len
From: Bob Wyman [mailto:bob@wyman.us]
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 pissed 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."
|
