RE: multiple "source" properties documents

Geoff,

please re-read the old discussion on the mailing list. RFC2518 specifies a
format that indeed doesn't make any sense (can you explain what the DAV:src
sub-element is for?).

So *if* this feature is to remain in RFC2518, at least the format needs to
be fixed (possibly in a way backwards compatible to RFC2518).

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

  -----Original Message-----
  From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On
Behalf Of Geoffrey M Clemm
  Sent: Friday, September 19, 2003 3:06 PM
  To: 'WebDAV List (E-mail)'
  Subject: RE: multiple "source" properties documents



  My perspective is a bit different.  The DAV:source property
  was designed for exactly the situation that Conal describes.
  He'd like a generic application to pop up the list of URL's
  and say "these are the sources".  There are no significant
  testing issues ... the format of the DAV:source property is
  well defined, and all a client is expected to do is to expose
  the specified list of URL's.

  So in Conal's case, I'd just expose this feature using the
  DAV:source property, and you are no worse off that if you
  just defined your own custom property, and that if enough
  folks do so, the property will become "undeprecated".

  Note: I am not arguing against deprecating the DAV:source
  feature ... I don't think the topic is significant enough
  to merit being re-opened ... I'm just saying that if you are
  an implementor and encounter a valid use for the DAV:source
  property, you should go ahead and use it instead of inventing
  your own custom property, even if it is deprecated in 2518bis.

  Cheers,
  Geoff


  Lisa wrote on 09/18/2003 07:41:56 PM:

  >
  >
  > > From what I read, the "source" property was a great idea but
  > > no-one ever implemented it, supposedly because it was too
  > > complicated and/or there was no perceived need.
  >
  > I'd characterize the reasons a little differently:
  >  1) The feature was underspecified, there was never enough
  >    information in the spec to be able to fully implement
  >    or interoperate
  >  2) Implementation interest was low -- we asked around to see
  >    who had implemented this feature and got no positive
  >    responses at all.
  >
  > > Eventually it
  > > was formally deprecated. Is this correct?
  >
  > The deprecation isn't final yet, but we are proposing to
  > deprecate it.
  >
  > > I've also read of
  > > the "translate" header, which I gather is a
  > > Microsoft-specific extension? I also gather that this only
  > > supports a one-to-one mapping between a document and its
  > > source, i.e. a document has one and only one source?
  >
  > Yes
  >
  > > My case is that I have a server which generates pages from
  > > multiple sources and keeps track of those sources in such a
  > > way that it could fairly easily support dav:source. I'd like
  > > editors to be able to edit the page and select which of the
  > > source documents to edit. But are there existing clients that
  > > will actually do that? Or are there other web-dav mechanisms
  > > that might support my use-case?
  >
  > Not that I know of.  You'd be the first to implement a
  > protocol feature to expose multiple mappings so nobody
  > to interoperate with and no tools to support your feature.
  >
  > If there is sufficient interest from implementors to make
  > forward progress on this, I'd recommend a separate draft rather
  > than resurrect the unimplemented, underspecified, and untested
  > feature in RFC2518.
  >
  > Lisa
  >
  >