Re: On the treatment of Design Objectives?

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.

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.

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

Cheers,
Yoshio

Received on Tuesday, 11 May 2004 12:51:43 UTC