Re: New requirements draft

>  The working group ought to be consistent in its stands. Could you 
> tell me why it would be a "bad thing" if variants are not dealt with. 
> If your criteria is that 80% of the customers are what you are 
> serving, then variants should be dropped from the requirements.

I remember a talk 15 years ago by John McCarthy about the failure
of standards groups which engage in "intellectual log rolling":
"I'll add your feature if you'll add mine". The problem is that
every little feature is just a little feature but by the time
you get done, you have something that is too big or too hard
to deal with. So I think it's good to be wary of arguments of
the form "well, we did X, so we should do Y". 

You're probably right that "configurations" and "variants" are
of equivalent complexity and that all of the things that people
say about "configurations" are also true of "variants". But 
it's not a strong argument.

In response to someone (Jim? the working group) being
> unconvinced of the need to develop an interoperability
> specification for configuration functionality right now.

You said:

< Hopefully, this note has helped.

but it didn't much. I don't understand your argument.

> It [leaving out configuration management as a requirement]
> is a bad thing because it has to do with clients exchanging 
> names with servers in a particular way

I don't understand why that's relevant

> and if we don't address it, 
> then anyone who wants to write configuration functionality will have 
> to get into the core of Web-DAV server request/response stream.

Why? This isn't obvious that they'll have to deal with configurations
in any particular way that interferes with normal Dav operations?
You mean that if you have configurations, you can't use normal dav
operations of checkout and checkin, or query versions? That none
of the existing operations will work? 

> The 
> configuration resolution has to happen before any part of the Web-DAV 
> server deals with the URI that is passed through the request.

Why? Aren't the individual objects versioned independently of
the configurations to which individual versions apply? It might
affect your IMPLEMENTATION but why should it affect the PROTOCOL?

> This 
> becomes even more hairy with collections.

The fact that something is hairy is a reason NOT to do it.

> To emphasize, I am 
> concerned about configuration relative addressing. 

I think mainly we should be concerned about relative addressing in
general, which may not work as we expect.

> This is a name 
> resolution issue.

THis is just confusing. _What_ is a name resolution issue?

> In my way of thinking this is too central to any 
> protocol for it to be left.

Your way of thinking just confuses me so far.

Larry
--
http://www.parc.xerox.com/masinter

Received on Thursday, 25 September 1997 04:02:25 UTC