Re: versions

Jack Bates wrote:
> How can I use WebDAV to discover multiple versions of a resource, such
> as different content types or dimensions?

I don't think we have a solution for that.

> I contributed a WebDAV module to the Gallery open source project:
> http://codex.gallery2.org/WebDAV
> 
> Recently I have worked on a WebDAV module for MediaWiki, implementing
> DeltaV and DASL: http://www.mediawiki.org/wiki/

That sounds like a very cool project.

Comment wrt to <http://www.mediawiki.org/wiki/WebDAV>: WebDAV is now 
defined in RFC4918.

> Organizations where I've installed Gallery and MediaWiki frequently
> integrate these projects with a Drupal CMS installation, so I'm writing
> a Drupal widget for creating links in Drupal "node" bodies to WebDAV
> resources.
> 
> The first challenge is: the Gallery WebDAV interface was intended for
> file system applications, so resource hrefs currently access Gallery
> "item" content, e.g. full size JPEG, PDF or AVI:
> http://freegeekvancouver.org/en/w/docs/fgv-startup_brochurev2.pdf
> 
> I want links created by my widget to instead access an HTML interface to
> the resource:
> http://freegeekvancouver.org/en/v/docs/fgv-startup_brochurev2.pdf.html
> 
> I understand that according to REST principles, the content type of the
> resource should not be included in its URI, that the Accept: request
> header should be used instead. So I guess an Accept: value of text/html
> could be used to access an HTML interface to the resource. Still, I have
> two problems:

On the other hand, another principle is that any important object should 
have it's own URI.

Both things can work together: although there is a single URI supporting 
conneg (content negotation), it still can make sense to expose separate 
URIs for the different types (using Content-Location, see 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.14>).

> 1) Widget should let users choose which version of the resource
>    to link to, so it should discover available versions. Maybe I can do
>    this with PROPFIND by returning multiple <D:getcontenttype> properties?

No, that would break the response format.

However, you may have a look at the original DAV:source property, see 
<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.13.10>.

>    Is there a way with pure HTTP, like returning multiple Content-Type:
>    headers on an OPTIONS or HEAD request?

Nope.

> 2) Created link should access the chosen version. Maybe I can do this
>    with the HTML/XHTML "type" attribute: <a href="..." type="text/html">

No, that attribute asserts what the type is, but doesn't specify an 
Accept header to send.

> The second challenge is: If the resource is an image, widget lets users
> resize a thumbnail which is embedded in the created link. Since Gallery
> builds resized derivatives of items, the widget should for performance
> use a derivative similar to the requested dimensions. Widget can
> discover resource dimensions with the Gallery <G:width> and <G:height>
> properties, but I have the same two problems above:
> 
> 1) Widget should discover dimensions of available versions of a
>    resource, but if PROPFIND returns multiple <G:width> and <G:height>
>    properties, widget can't determine which dimensions correspond to
>    which resource version. Even if dimensions are advertised as one
>    property: <G:dimensions>, if PROPFIND returns multiple
>    <D:getcontenttype> and <G:dimensions> properties, widget can't
>    determine which dimensions correspond to which content types, e.g. if
>    the full size image is 1024x768 image/jpeg and an available
>    derivative is 240x160 image/png

Again, you can't return multiple instances of the same property within 
one DAV:response element (at least not without breaking the spec).

> 2) To my knowledge, there is no way to request particular dimensions in
>    an HTML/XHMTL <img src="..."> tag.
> 
> All this leads me to understand I need to use separate resources for the
> multiple versions of a resource, similar to the DeltaV specifications'
> use of separate resources for multiple versions, e.g.
> 
> w/docs/fgv-startup_brochurev2.pdf	// Full size application/pdf
> v/docs/fgv-startup_brochurev2.pdf.html	// HTML interface
> w/ver/docs/fgv-startup_brochurev2.pdf/0	// 240x160 image/png
> [...]
> 
> My challenge then is for widget to discover available versions. I
> understand DeltaV was really intended for accessing versions of
> resources changing over time, but maybe I can use the DeltaV
> D:version-tree report to discover multiple versions of a resource not
> under version control?

I don't see why you would want to re-use DeltaV for that. Just define 
your own report, or simply a new property holding the hrefs.

> In this tree, it's clear Gallery derivatives can be expressed as
> children of the full sized resource. It's less clear what the
> relationship between the HTML interface and the full sized image should
> be...
> 
> Feedback on these issues from members of the WebDAV working group is
> much appreciated!
> 
> Much thanks for all your work on open standards. Jack

Best regards, Julian