Re: On the treatment of Design Objectives?

On Tue, 2004-05-11 at 11:51, Yoshio Fukushige wrote:
> Thank you, Dan,
> 
> Dan:
> > Optional protocol elements work against interoperability, so I would
> > like to see more motivation. Do you have any particular topics
> > in mind for optional protocols?
> 
> To me things seem just the opposite way.
> 
> If we don't make optional protocol elements, developers could invent their
> own protocols
> for the functionality, which will lead the interoperability.

That's natural and good, no? Implementation experience should
come before standardization.

> If we do have protocols for optional functionality, the developerS who want
> to support the functionality
> can follow it, and the more the numbers of them, the more interoperability.

That's not my experience.

For every optional feature of a specification, there's a risk
that party A requires it and party B chooses not to provide it,
and hence A and B do not interoperate, even though it looks
like both conform to the specification.

Perhaps the fault is on party A for depending on a feature
that's not guaranteed to be provided. Then in fact noone
can rely on the feature, so it's not really standardized
after all. Why keep it in the specification?

Perhaps the fault is on party B for not providing a
needed feature. Then why was it optional? Why was B
not required to provide it?

W3C provides value by getting parties like A and B
to agree on what are the right features to catalyze
a marketplace. Any time we don't completely nail
down exactly what the right features are, we put
the network effects of the new spec at risk.

In quite a few cases, W3C specs do have optional
features, but these come at a cost, and that cost
ought to be justified.

It's almost always better to make separate, smaller,
orthogonal or layered specifications than to have
specs with optional features. Then party B can
make a clear claim to conform to "WidgetML basic"
and not the "WidgetML hyperspeed extension", and
party A, who needs to go at hyperspeed, will know
to shop for it by name.


> > I understand an objective to be something like a goal; i.e. the WG
> > would like to get it done, but the WG is prepared to declare
> > victory even if we haven't done it.
> 
> Well, those are of type (1) in my wording:
> 
> > > I think there are two types of optional functionalities:
> > > (1) those would require too much time to make standards for
> > > (2) those relatively easy to make standards for, but not suitable to
> force
> > > all implementations to support
> 
> And I think at least 4.3 Non-existent Triples and 4.4 User-specifiable
> Serializatin belong to type (2).
> 
> 4.5 Aggretate Query seems difficult, but it is indispensable in UC like 2.4
> and 2.6 where user client
> queries to more than one DB.

OK, now that you're more specific, I see your point.

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.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
see you at the WWW2004 in NY 15-21 May?

Received on Tuesday, 11 May 2004 18:42:23 UTC