RE: Ideas: GETSRC & MULTIPUT

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead
> Sent: Tuesday, October 30, 2001 2:17 AM
> To: Roy T. Fielding
> Cc: WebDAV
> Subject: RE: Ideas: GETSRC & MULTIPUT
>
>
> > Under what conditions did it not work?  Do you mean just never
> > implemented?
>
> The source link was never implemented.
>
> The two reasons I have heard for this (there may be more) are:
>
> ...
>
> (b) There was insufficient direction given to client implementors
> on how to
> use and handle the source link, especially in the case of multiple sources
> for a given resource. The user interfaces of almost all existing
> DAV clients
> implicitly assume there is just a single "source" representation for a
> resource. Perhaps DAV's closeness to a traditional network file system
> protocol is coming back to haunt us. Certainly, it would involve
> significant
> UI and operational shifts to accommodate more.
>
> I think existing client UIs could handle a standard mechanism to get at 1
> source representation for a resource. I do not think they can handle a
> mechanism that provides access to multiple source representations. Efforts
> to do so will, like the source link, be ignored. I think it is instructive
> that the only mechanism that has gained any traction so far is
> the Translate
> header, which provides access to one source representation.

I don't quite agree. If a client is able to select an optional source
resource, it should't have problems offering a selection multiple sources.
However, the server would need to assist in labeling them.


<quote>
Currently, the RFC only gives the following example:

   <?xml version="1.0" encoding="utf-8" ?>
   <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
     <D:source>
          <D:link>
               <F:projfiles>Source</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/main.c</D:dst>
          </D:link>
          <D:link>
               <F:projfiles>Library</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/main.lib</D:dst>
          </D:link>
          <D:link>
               <F:projfiles>Makefile</F:projfiles>
               <D:src>http://foo.bar/program</D:src>
               <D:dst>http://foo.bar/src/makefile</D:dst>
          </D:link>
     </D:source>
   </D:prop>

In this example the resource http://foo.bar/program has a source property
that contains three links. Each link contains three elements, two of which,
src and dst, are part of the DAV schema defined in this document, and one
which is defined by the schema http://www.foocorp.com/project/ (Source,
Library, and Makefile). A client which only implements the elements in the
DAV spec will not understand the foocorp elements and will ignore them, thus
seeing the expected source and destination links. An enhanced client may
know about the foocorp elements and be able to present the user with
additional information about the links. This example demonstrates the power
of XML markup, allowing element values to be enhanced without breaking older
clients.
</quote>

This is extremely confusing (at least it was to me), because:

- the individual link elements have a src element that is identical to the
request URI (which isn't shown). Why does it exist at all?

- there's no common way for a client to decide what kind of line this is.

So, taking this in account and moving to a XLink-compatible syntax would
give us instead:

   <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
     <D:source-set>
          <D:source xlink:href="http://foo.bar/src/main.c"
xlink:role="UriDescribingTheRole" xml:lang="en">
            source file
          </D:source>
          <D:source xlink:href="http://foo.bar/src/main.lib"
xlink:role="UriDescribingTheRole" xml:lang="en">
            library file
          </D:source>
          <D:source xlink:href="http://foo.bar/src/makefile"
xlink:role="UriDescribingTheRole" xml:lang="en">
            makefile
          </D:source>
     </D:source-set>
   </D:prop>

A UI could then use the text content of the D:source element as a
human-readable description of the type of link.

Received on Tuesday, 30 October 2001 07:09:28 UTC