- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Wed, 24 Sep 1997 05:52:22 -0700
- To: "'Sankar Virdhagriswaran'" <sv@crystaliz.com>, "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
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