Mapping DAV link properties to HTML/Atom/Http link relations
Julian Reschke <[email protected]>
| Newsgroups | gmane.ietf.webdav |
|---|---|
| Message-ID | <[email protected]> |
Hi,
some while ago, the Atom feed format has introduced link relations that
either can use a short name (through an IANA registry), or a full URI as
identifier.
<http://tools.ietf.org/html/draft-nottingham-http-link-header-02>
generalizes this concept, introducing a single registry for both (X)HTML
and Atom link relations, and also re-introduces the HTTP Link header
(defined in RFC 2068, but dropped from RFC 2616).
In WebDAV, we already have properties of type link implicitly (by
containing DAV:href elements). So, for instance, the DAV:checked-in
property defined in
<http://greenbytes.de/tech/webdav/rfc3253.html#rfc.section.3.2.1>, could
be interpreted to also define a link relation identified by the URI
"DAV:checked-in".
Potential benefits:
1) Use in HTTP Link Header
A server could expose the property value in an HTTP response header,
independently of WebDAV:
HEAD /foobar HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: text/plain
Link: </versions/foobar/1>; rel="DAV:checked-in"
2) Response bodies of WebDAV requests that affect the set of links could
be made more useful, such as in:
VERSION-CONTROL /foobar HTTP/1.1
Host: example.com
HTTP/1.1 201 OK
Content-Type: application/xml+xhtml
Content-Length: xxx
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Resource put under Version Control</title>
</head>
<body>
<p>
The resource has been put under version control; the
version history is located at <a rel="DAV:version-history"
href="/histories/123">/histories/123</a>, and the initial version is <a
rel=DAV:checked-in" href="/versions/456">/versions/456</a>.
</p>
</body>
</html>
Open issue: WebDAV uses QNames to identify properties, and they do not
always map well to absolute URIs -- the simplest approach to address
this is by choosing namespace URIs wisely...
Feedback appreciated,
Julian