RE: multiple "source" properties documents

I agree that the property could be extended in a variety of 
interesting ways, but I do not consider that to imply that the
property is underspecified, but rather that the property is
appropriately extensible.   More comments below:

"Lisa Dusseault" <lisa@xythos.com> wrote on 09/19/2003 03:30:15 PM:

> It does seem reasonable to use the source property today insofar as 
> it can be used for simple cases.  It's a good bet that when 
> eventually enough implementors need the feature and work on the 
> specification, they can likely reuse the same property name. 
> However, the format within the property name could be significantly 
expanded.
> 
> Here are some of my reasons already posted for believing the 
> property is underspecified:
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html
> 
> Other minor and major reasons why the source property is underspecified:
>  - Unlike other places where URLs appear in property values, URLs in
> the source property value are not shown in <href> tags.  Was this 
intentional?

I assume so, but I doubt there was a good reason for it.

>  - What do multiple 'link' elements mean semantically?

The link elements have no semantics beyond stating that the specified
DAV:dst resources are inputs to a process that creates the DAV:src
resources.  Extensions could provide more specific semantics, but this
general property would be enough to allow human users to do interesting
things with the information.

>  - Can the URL in 'dst', in a given source property value, be the 
> same URL that the source property appears on?  Can it be different?

Yes.  What is not forbidden is allowed.

>  - Is this property scalable?  Sharemation's WebUI runs on hundreds 
> of java files, with hundreds of java class files, a couple dozen 
> java libraries, hundreds of text files including resource files, and
> dozens of images.  Would the 'source' property for the URL 
> /xythoswfs/webui on www.sharemation.com really contain over a 
> thousand links plus information on how they tied together?  Since 
> some of these files can be changed without a recompile, would this 
> property have to be dynamically calculated?  By what process?  To 
> really handle this kind of situation, which isn't all that uncommon,
> the source property would have to point to some other authority or 
> way to browse source files.  Perhaps the source property could point
> to some directory hierarchy where the source files are all stored & 
> there would be more information within the properties of resources 
> in that hierarchy.

One could certainly introduce scalability extensions, but there are many
processes that only take a few resources as input and those would not
require these scalability extensions.

Cheers,
Geoff

> -----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:06 AM
> 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
> > 
> >

Received on Friday, 19 September 2003 15:56:25 UTC