RE: multiple "source" properties documents

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?
 - What do multiple 'link' elements mean semantically?
 - 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?
 - 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.
 
Lisa

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