RE: Ideas: GETSRC & MULTIPUT

Roy Fielding writes:
> So the solution is to make it impossibe to edit resources that consist of
> multiple sources?  That'll really piss off my customer who has spent most
> of this year creating a site that is entirely controlled by a content
> management system, where each resource consists of a dynamic mapping to a
> database entity catalog.  Each Web page consists of dozens of
> source elements.

How would you propose that authoring tools present this scenario to their
users?  The tool does a PROPFIND, gets back the source property, and finds
there are dozens of links. Now what?

You could pop up a list of the sources, and say "pick one". But without
providing any guidance as to which source corresponds with a particular
aspect of the browser-based view, the user doesn't have much guidance on
which one to select. It doesn't sound like a compelling user experience.

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.

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

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

- Jim

Received on Tuesday, 30 October 2001 17:02:36 UTC