- From: Greg Stein <gstein@lyra.org>
- Date: Wed, 31 Oct 2001 03:00:43 -0800
- To: Jim Whitehead <ejw@cse.ucsc.edu>
- Cc: "Roy T. Fielding" <fielding@ebuilt.com>, WebDAV <w3c-dist-auth@w3.org>
On Tue, Oct 30, 2001 at 01:58:36PM -0800, Jim Whitehead wrote: >... > There are two kinds of authoring tools: ones that are structure aware, and > ones that are not. Structure-aware tools (i.e., a tool that understands a > given page is comprised of N other pieces) will be programmed to know the > relationship between sub-elements and the end-user visible Web page, and > will have developed a naming convention that it understands. The source > property won't provide these tools much value. > > Structure unaware tools just allow the user to pick a URL and edit it. There > is no notion of structure. Such a tool could use the source property to find > other parts, but could still only allow a user to pick one of them to > individually edit. A person using these tools would eventually need to > understand the naming convention used by the parts and the whole. > > Hence, I'm not convinced the source property, as currently defined, provides > much value to any known class of client. That is an improper conclusion. You only posed two cases, and both deal with a resource that is comprised of many other resources. If a resource is produced from a *single* item, then the source property is of tremendous value. That unaware tool will take me there, and I can get my editing done. Nothing complicated there, yet incredibly useful. > There are really several classes here: > > (a) when the mapping of resource to authorable subparts is 1::many > (b) when the mapping of resource to authorable subparts is 1::1 (as with > server-side includes), and the authorable rendition of the resource isn't > returned by GET > (c) when the mapping of resource to authorable subparts is 1::1, and the > authorable rendition of the resource *is* returned by GET (e.g., a Word > document) > > Something like "the inverse of PUT" would be handy for case (b). WebDAV only > provides good support for cases (c) (Office, Acrobat, drive mappers) & (a) > (Go Live, Dreamweaver). WebDAV also provides quite fine support for (b). I've got empirical evidence of people doing exactly that. I've done it myself. Don't warp your cases so that you can draw a desired conclusion :-) The 1::many problem is hard, sure. But the existing solution provides structure for that. Maybe you could argue some extensions, such as a DAV:displayname for each link pair, but the concept is sound. > > Feel free to define yet another distributed filesystem protocol within any > > other working group of the IETF. I'd rather wait until it gets > > implemented correctly than reduce the standard to something that doesn't > > meet the need. > > Today, the most frequently used WebDAV client is Web Folders. A valid way > to view WebDAV is as a network file system protocol. While this was never my > goal, the fact remains that the majority of WebDAV users would never notice > if PROPPATCH, LOCK, and UNLOCK were turned off. This is changing as more > full-featured collaborative authoring clients become available, and enter > into widespread use. But right now, and into the forseeable future, DAV as > Web Filesystem is an important user model. Okay, fine. But what does that have to do with GETSRC or the source property? Great -- so people can browse... what about it? The capabilities offered by Web Folders are also going to be independent of the source stuff we're discussing. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Wednesday, 31 October 2001 05:55:06 UTC