RE: multiple "source" properties documents

I see.

That makes sense, but definitively should be explained. As far as I remember, this is the very first time since I'm reading this list (2,5 years) that somebody was actually able to explain why this element is there.

So how do we proceed? Should we try to get it into RFC2518bis (which would require demonstrated interoperability), or should we try to come up with a separate document? Who is prepared to implement the property within the next few months?


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 6:36 PM
  To: 'WebDAV List (E-mail)'
  Subject: RE: multiple "source" properties documents



  I don't think the format needs to be changed, but it certainly 
  would need to be more clearly described.  I am continually 
  amazed at how such an otherwise sensible group of authors could have 
  chosen a node named DAV:tgt to hold the URI of the source, 
  and a node named DAV:src to hold the URI of what is usually the 
  resource itself.  Didn't they at list flinch or grimace at 
  the sentences: 

  "The destination of the source link identifies the ... source 
   of the link’s source." 

  and 

  "The source of the link is typically the URI of the resource 
   on which the link is defined." 

  One could make a good argument that this poor naming choice alone 
  merits deprecating the feature :-). 

  But back to your actual question, if there are multiple outputs 
  of the processing step (i.e. it produces not only the resource 
  identified by the request-URI, but several other resources), 
  then it is useful to have the DAV:src nodes to indicate what 
  those other output resources are. 

  Cheers, 
  Geoff 

  Julian wrote on 09/19/2003 09:18:29 AM:

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