- From: Dan Connolly <connolly@w3.org>
- Date: Tue, 11 May 2004 17:42:26 -0500
- To: Yoshio Fukushige <Fukushige.Yoshio@jp.panasonic.com>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
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