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

Dr. Ernie Prabhakar drernie at opendarwin.org
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  
*assumed*.

> Putting on a different hat, I'll point out another option ...
> put the metadata *in* the data:
>
>     http://www.adobe.com/products/xmp
>
> 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:

http://www.w3.org/TR/REC-html40/struct/global.html#h-7.4.4

:-)

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

http://www.w3.org/TR/REC-html40/struct/global.html#adef-profile

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  
access.

http://microformats.org/wiki/rest/property

-- Ernie P.

= The Problem =

HTML has long used the [http://www.w3.org/TR/REC-html40/struct/ 
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 [http://microformats.org/ 
about/ microformat principles] and practices
# It should be consistent with URL [[rest/opacity]] (properly  
understood)

== &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. [http://www.macromedia.com/cfusion/knowledgebase/ 
index.cfm?id=1c6b723 ColdFusion], and eases human-readability.

= Examples =
* TBD

= 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 [http://lists.evolt.org/archive/Week- 
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