RE: On the treatment of Design Objectives?

> > But if there are features that are outside a core that absolutely
> > every implementation needs to provide, I would much prefer not to
> > spend the time to standardize them in our first version, even if
> > they would take less time than some other features.
> 
> I want to know other members' opinion on that point.

Am I correct in assuming that Dan's statement is missing a 'not'?
"...if there are features that are outside a core that NOT absolutely
every implementation needs to provide..."

If so, I agree with Dan's sentiment. I freely admit that there is a
theoretical argument to be made that more standards are better, no
matter what, but in practice I don't think it works that way.

Standards bodies don't always come up with the best solution, or even a
very good solution, and the "more standards are better" philosophy only
stands up if everybody always chose to adopt any standard if it was
available.

That's not my experience with industry response to standards. Problems
that need interoperability solutions immediately force the adoption of
standards, even if the standards suck in many ways. If people can get by
without a standard for a little while, then they'll spend the time
trying to come up with solutions that suck less than the standard does.
Worse, there's even the temptation to try to own an emerging technology
space, so there's an incentive to avoid an existing standard as an
attempt to leverage a current position into future dominance in that
segment.

Add to all this the notion that (particularly within the W3C and the
semantic web) additional standards tend to "dilute the brand", and the
short story is that premature standards can often have negative impacts
on true industry standardization in the long term.

I think it's important to address the real problems that are preventing
real RDF applications from being written today, and to me those problems
center on the inability to extract data from RDF.

Received on Tuesday, 11 May 2004 21:31:30 UTC