relProperty Re: [uf-rest] Roy Fielding on WebDAV and PROPs

Dr. Ernie Prabhakar drernie at
Wed Apr 12 14:55:14 PDT 2006

Hi Larry,

On Apr 12, 2006, at 2:11 PM, Larry Masinter wrote:
> After Yaron's bed time story and a 9 year slumber...
> What was I thinking? Clearly, URL munging isn't so bad, if you
> add:
>> where ",properties" is a site-configurable string. It needs to be
>> advertised by some sort of site metadata; e.g., in OPTIONS

Right, the key is that it has to be *advertised*, not implicitly  

> Putting on a different hat, I'll point out another option ...
> put the metadata *in* the data:
> For the descriptive metadata for which this is appropriate,
> you don't need a separate URI, the latency of a separate
> GET request, etc.

Yeah, I think someone has already come up with a convention for  
embedding metadata in web documents:


As it happens, these in fact use the same profile as microformats:

The issue at stake, though, is how to advertise metadata that is  
*not* a proper part of the actual document, which is why I think we  
need <link> or Link:

I've started a Wiki page to capture the discussion so far.  Please  
feel free to add questions or comments; let me know if you need write  

-- Ernie P.

= The Problem =

HTML has long used the [ 
global.html#h-7.4.4 meta] tag for metadata to describe the  
''contents'' of a document.  While this works well for "intrinsic"  
metadata related to authoring, there's no equivalent function for  
"extrinsic" metadata provided by the server or external sources.

To address this need, [WebDAV] defined a new set of "PROP" methods to  
create, search, and retrieve '''properties'''.  Unfortunately, in  
addition to defining a whole new protocol this violates the [rest]ful  
notion of each resource having a URL for manipulating it.  This  
raises the question, "What is the RESTful way to use HTML and HTTP to  
provide useful properties."

= Proposal =
== relProperty ==

Our proposal, currentlly called "relProperty", is motivated by the  
following principles:

# Every property must have at least one well-defined URL which can be  
retrieved and updated.
# There must be an easy way to discover all the properties associated  
with a given document.
# It must be simple to implement on existing web servers without  
requiring non-trivial modifications
# It should respect and build on existing [ 
about/ microformat principles] and practices
# It should be consistent with URL [[rest/opacity]] (properly  

== &lt;link> ==

Together, this implies that that the optimal way to associate a  
property with a document is via the HTML [ link] tag (or the  
equivalent HTTP "Link:").  This provides the requisite mechanism for  
telling the client how to construct an appropriate URL for getting or  
setting each property, as in:

  &lt;link rel="property" href=".;prop1">

== ;property ==

It is conventional, but not mandatory, to use a semicolon (";") as  
the first character of each property.  This follows the convention  
used in, e.g. [ 
index.cfm?id=1c6b723 ColdFusion], and eases human-readability.

= Examples =

= Open Issues =

* Can properties be chained together? If so, are they retrieved in  
parallel, or would those be subproperties?
* Would we need to worry about [ 
of-Mon-20020114/065707.html semicolon exploits]?
* Are there other conventions we should follow/avoid?
* Should the "Link:" tag itself be declared in HTTP "OPTIONS"?

More information about the microformats-rest mailing list