W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2007

versions

From: Jack Bates <ms419@freezone.co.uk>
Date: Fri, 10 Aug 2007 15:42:18 -0700
To: w3c-dist-auth@w3.org
Message-id: <20070810224218.GU13430@tor.lat>
How can I use WebDAV to discover multiple versions of a resource, such
as different content types or dimensions?

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/

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:

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

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

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

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?

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

Received on Friday, 10 August 2007 22:42:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT