W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2006

Re: WebDAV capabilities in HTML?

From: Jim Whitehead <ejw@soe.ucsc.edu>
Date: Thu, 12 Oct 2006 08:21:05 -0700
Message-Id: <52E1D047-36EA-4CCA-893D-3FEB13967A39@cs.ucsc.edu>
Cc: Julian Reschke <julian.reschke@gmx.de>, Rohit Khare <rohit@commerce.net>
To: WebDav WG <w3c-dist-auth@w3.org>

OK, it appears I wasn't clear enough in my original post. Let me try  

I am interested in the kinds of applications that might be possible if:
a) a standard Web browser can act as a WebDAV client
b) new XHTML tags existed whose semantics mapped to one or more  
WebDAV methods

I recognize that current web browsers currently can execute WebDAV  
methods via Javascript. This requires a fair degree of  
sophistication, and raises cross-browser compatibility issues. What  
if some set of WebDAV operations were accessible via XHTML elements?  
This would permit these operations to be specified in an XHTML  
document simply, ideally with greater cross-platform compatibility.

At UC Santa Cruz we have been playing around with this capability. We  
have a Firefox implementation that traps the display of our new  
"WebDAV HTML elements", executes the appropriate WebDAV commands,  
then modifies the document's DOM model based on the results of the  
WebDAV operations.

An open question is how someone might use this capability. We're  
unclear on exactly which WebDAV functionalities to expose via HTML,  
and what scenarios these capabilities might support.

One scenario we've explored so far is Weblogs. Consider a weblog data  
model in which every message is a separate DAV resource in a per-user  
collection. If user jim has 3 messages, this might result in a  


This collection contains resources:


The "msg*" resources each have the properties:

{namespace}, title
{namespace}, date
{namespace}, contents

Where the {namespace} is anything other than "DAV:" :-)

We've been exploring what WebDAV XHTML tags you would need to have in  
index.html such that a browser loading this resource would be able to  
make a nice display of the weblog for "jim".

Our index.html looks something like (inside the <body> element):

<resource-iterate ignore-self="true">
   <p><b><getprop namespace="{namespace}" name="title"/>,
   <getpropr namespace="{namespace}" name="date"/></b></p>

    <p><getprop namespace="{namespace}", name="contents"/></p>

The semantics of getprop are to execute a PROPFIND and take the  
resulting property value XML stream (i.e., we strip the WebDAV XML  
elements in the PROPFIND response) and inject it into the DOM at the  
point of the getprop element, replacing this element.

The resource-iterate element does a "for each" over all the resources  
in a collection. By default, it is the collection containing the  
current resource. The ignore-self attribute says to ignore the  
current resource in the iteration. The XHTML sequence inside resource- 
iterate is injected (executed) once for each resource in the  
iteration set.

What I take away from this scenario:

A mapping of WebDAV capabilities to XHTML is more than just a one-to- 
one mapping of XHTML to WebDAV methods. By considering the specific  
Weblog scenario, we see the need for the resource-iterate capability.  
Hence, having a rich set of other scenarios would be useful in  
determining the requirements for DAV in XHTML.

One can view this as creating a new kind of property-driven web  
application. In this kind of web application, there is no explicit  
database (it's hidden behind the property interface), and the client  
is responsible for creating the final presentation seen by the user.  
This has the effect of pushing most of the functionality away from  
the center to the edges, that is, the clients. This may result in  
greater scalability of such web applications (the hedging is due to  
the fact that such applications may generate large numbers of  
PROPFINDs -- client side PROPFIND optimization would be important for  
good performance). However, despite being executed on the client,  
such web applications are still configuration controlled on the  
server. If a new application is desired, the provider (server  
operator) just changes the index.html contents.

Of course, an open issue is how to handle property-driven web  
applications that write content to properties, since this raises  
authentication issues. At present, WebDAV mostly relies on HTTP  
authentication for security, while a more web-application-logon-style  
might be better for users.

As well, these client-side web applications currently couldn't have  
very rich semantics, since there are no control flow elements in  
XHTML. But, perhaps Javascript could be used for this.

I'm interested in any ideas you may have on scenarios for using DAV  
in XHTML. I view implementation as being fairly straightforward --  
the difficult question here is what you might be able to do with this  


- Jim
Received on Thursday, 12 October 2006 15:21:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:36 UTC