RE: New requirements draft

On Tuesday, September 23, 1997 2:34 PM, Sankar Virdhagriswaran 
[SMTP:sv@crystaliz.com] wrote:
> I see that section 5.10 says that the requirements on variants will be
> addressed in another document. Fine. But, what about configurations and
> configuration relative addressing. At a minimum, I would want to have a
> section that has something similar to section 5.10, but that addresses 
the
> issue of configurations and configuration relative addressing. The way 
the
> requirement document stands, I take exception with this omission. (am I
> missing something?)

Sankar,

The appropriate time to have raised these concerns was during the two week 
working group last call period which ended last Friday.  Comments now 
should be specific to those additions made to the document since the end of 
the WG last call.

However, looking through the archives I do note that your concerns on 
configurations have been voiced many times, and perhaps have not been 
responded to as effectively as they could have been.  Which is not to say 
they have never been explicitly addressed.

On July 23, 1997, I responded to your email titled, "Our Concern," from 
which the following is excerpted:

> And, there is
>no way to specify that the same version is active in different
>configurations at the same time.

There are currently no plans to support configurations (which I define to
be versioned collections of versioned resources) within WebDAV.  Support
will only be provided for managing the revisions of a single resource.
However, the versioning support should not preclude the future development
of configuration support.

---

However, let me restate my position on this topic, which I believe reflects 
the view of the working group (subsequent posts may prove me wrong).

==> The requirements document does not mention support for configurations. 
 This is intentional.

I honestly do understand the utility of configurations, and hence my lack 
of desire to provide support for configurations is not based in ignorance 
of their virtues.  Rather, my objection to configuration support is based 
on my perception that there are thorny, complex issues surrounding this 
topic, and my belief that the state of the art may not yet be sufficiently 
advanced to standardize such functionality.

For example, while we could provide support for freezing the state of a 
collection, and provide check-in and check-out capability on a collection, 
this avoids the difficult issue of determining what should be the 
membership of that collection.  Should the membership be only the release 
"2.0" members, or should it be the result of a search on the values of some 
properties, or should it implement a change set system?

At present, I see a trend in the software CM tools industry towards 
providing change set capability.  However, this is different from the 
majority of current CM systems.  If we were to chose a change set solution, 
how would this map to legacy versioning repositories?  In fact, chosing any 
one way of placing the members inside a collection will undoubtedly favor 
some systems, and preclude others.

Because of my perception of the complexity of this issue, I think it is 
best to avoid it.  Does that leave WebDAV a gutted shell?  No.  Versioning 
capability will still allow a wide variety of clients, ranging from word 
processors to software development environments to workflow systems, the 
ability to version individual resources.  Functionality related to 
configuration management will be accessed either locally, via the 
configuration management program's native interface, or via one of the many 
Web user interfaces, e.g., Forms, Java applets, etc.  To me this sounds 
like a "have your cake and eat it too" situation -- all clients can depend 
on the frequently used versioning primitives, while advanced users still 
get the benefits of configuration management.

So, the distinction is that the full range of configuration management 
capability will still be accessible, however, it may not be interoperable. 
 Hence, to convince me, and this working group that configuration support 
should be included in the requirements document you need to convince us why 
it would be a "bad thing" if configuration support were not 
*interoperable*.  Convincing us of the benefits of configurations won't cut 
it -- I think the working group understands the value of configurations, 
but is unconvinced of the need to develop an interoperability specification 
for configuration functionality right now.

- Jim

Received on Tuesday, 23 September 1997 20:58:22 UTC