OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Pushing all the buttons

[ 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 
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. 

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS