[log in to unmask] wrote:
> John Stracke said:
>
> Promotion comes from companies promoting
> their own products that incorporate the standards;
>
> Thankyou! This is why I thought it would be a good idea to have Microsoft
> embracing DC.
> Let's face it - they will either embrace DC or develop their own ... they
> have to do _something_ ... I'd like to see that something be DC. If not,
> whatever they develop will be a powerful competitor to DC.
Agreed. The usual counterargument is that they may adopt DC, extend it, and
get the marketing benefits of saying the support the standard while at the
same time locking in their users (since their users will be creating metadata
that other software won't recognize). It's still better to have them support
it than not, though, since:
1. At a minimum, their users will be able to read other software's metadata
(which will increase the client base available for other software).
2. Most likely the MS tools will be able to generate standard DC; their
proprietary data would be just be extra. The risk is that an MS tool may
have a UI that makes the proprietary fields prominent, so that users want
to fill them out and then don't bother with the standard ones.
3. All of this is not such a big deal as in other protocols, since it's
easier to figure out what MS's proprietary fields mean (the manual should
tell you, after all :-) than to, say, reverse engineer a streaming
protocol. My guess would be that they just wouldn't bother to subvert
DC; it's a case where the competitive advantages are swamped by the PR
problems.
--
/=============================================================\
|John Stracke | My opinions are my own | S/MIME & HTML OK |
[log in to unmask]
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp. | by its lack of scalability. -- John Kirch |
\=============================================================/
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
