Subject: RE: multiple "source" properties documents

From: "Lisa Dusseault" <[email-masked]>
Date: Thu, 18 Sep 2003 16:41:56 -0700

> 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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Sep 2003 12:35:30 -0400

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: [email-masked] [mailto:[email-masked]]
> 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: "Conal Tuohy" <[email-masked]>
Date: Fri, 19 Sep 2003 11:19:43 +1200

I'm writing to ask about the "source" property which supposedly can be used to identify the URIs of multiple source documents. I've read a lot of the discussion in the list archive but I was still left slightly confused as to the status of this property. I'm sorry if I appear to be bringing up an old controversy and rehashing it ... I've only recently joined the list so I can find out about it.

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. Eventually it was formally deprecated. Is this correct? 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?

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?

Currently I'm working on a system where, by adding a parameter to the URI of a page, the editor can access a page containing links to the source documents. Then they can select the source that interests them. I've also considered implementing this feature as an Annotea service, but I'd prefer to use just webdav if I thought there'd be client-side implementations that would use it.

Cheers

Con

--
Conal Tuohy
Senior Programmer
(04)463-6844
(021)237-2498
[email-masked]
New Zealand Electronic Text Centre
www.nzetc.org

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 19 Sep 2003 15:18:29 +0200

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

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]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

  Cheers,
  Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Sep 2003 09:05:49 -0400

Cheers,
Geoff

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 19 Sep 2003 19:16:27 +0200

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 

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]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

  and 

  Cheers, 
  Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 19 Sep 2003 15:56:20 -0400

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" <[email-masked]> 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

> Sent: Friday, September 19, 2003 6:06 AM

---

From: "Lisa Dusseault" <[email-masked]>
Date: Fri, 19 Sep 2003 12:30:15 -0700

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: [email-masked] [mailto:[email-masked]] On

Cheers, 
Geoff