[
Lists Home |
Date Index |
Thread Index
]
Bob Foster wrote:
>How is it you're going to ensure that X support the method that becomes
>popular in Y? How is it than Y is going to be _able_ to support the X
>method? (Names changed to protect MS, I mean X.) What prevents them keeping
>their method a secret or patenting it?
>
Nothing. It is up to users to boycott monopolized technologies, and for
standards bodies to
steer clear of them, just like with any technology. If vendors want to
augment the common
methods with their own proprietary method that has some advantage, great.
As long as the infrastructure supports pluralism (in this case,
compression negotiation
or content negotiation), it is great if they support proprietary
encodings (for data transmission).
But when plurality is allowed, the issue of which one to support has a
hope of being a technical
decision rather than a competitive decision. Data interchange (if that
is the purpose of binary
infosets) is best served if the lower layers can be altered to taste:
buying into a higher layer
(e.g. .NET or whatever) should not require you to buy into a whole
stack, particular encodings,
particular protocols, etc. In the long run, plurality wins because
monolithic system and tied
stacks become unworkable and unorganic.
If your question is code for how can we force Microsoft to support
something, I think the
answer is obvious merely by posing it directly! Of course we cannot--it
is their business
(and they claim to be more interested in the upper layers); but what we
can do is make
sure the standards-based infrastructure supports anyone supporting
common protocols
when it becomes in their advantage to do so. Big companies can suffer
just as much
from technological lock-in as small users can; I think it is a mistake
to see the arguments
for plurality in David-and-Goliath terms.
To use my regular analogy here: look at how many great products MS is
building on top
of W3C XML Schemas, but what happens if the market is bored or scared by
them?
With big monolithic standards, MS cannot go back and say "These parts
are fine but we
need a complete revision of these parts quick", both because of the
difficulty of updating
monolithic standards, and because implementations of monolithic
standards may not
have been written with a view to modularity; you cannot upgrade it in
dribs and drabs.
(I wouldn't want to take this too far: obviously schemas for creating
PSVIs are different
from compression formats in that the former is a gateway to the
application while the
latter is a gateway to lower layers. )
If the purpose is data archiving in any way, then the tradeoffs change:
text is definitely the way
to go.
Cheers
Rick Jelliffe
|
