Re: On the treatment of Design Objectives?

Hello,

Dan said:
> > 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.

Well...
The later the standardization, the more the adapting cost would be, I think.
And an optional functinality of type (2) in my wording (i.e. those
relatively easy to make standards for, but not suitable to force all
implementations to support) should have enough implementation experience by
now.

If the situation is that there's no functionalities of such kind, then our
discussion ends.
I'm happy with not having those of type (1) in the specification or leave
them just as "desin objectives."
... type(1): those which would require too much time to make standards for

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

In this case, the server B could answer to the client A
"Sorry, we don't support that feature, will you say it in other words?"
or "Sorry, all we can give you is this (providing its best answer)"
and A shoud be ready for it, for the optional features is labeled OPTIONAL
in 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?

It's to provide further interoperability among languages that support the
optional functionalties.

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

It's because optional functionality could be burdonsome for small servers
(and maybe so for some clients, too?).

If we keep some functioality OPTIONAL, providers who want to implement only
the mandatory part of the specification
can provide more compact servers.

In other words, OPTIONAL requirements are the ones to be included in the
future specification
when computational or device costs should be considerably lower than now.

> 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 agree with you on this point.
It should be better.

My consern, however, is that the costs to support each optional features
coud be differ (or couldn't be shared),
and without some theoretical justification, our layering/clustering
functionalities wouldn't get people's support.
"Why should I implement the optional functionality B paying extra cost when
I need only A?"
# In OWL case, we have theoretical justification, don't we?

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

I want to know other members' opinion on that point.

Best regards,
Yoshio

Received on Tuesday, 11 May 2004 20:43:20 UTC