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
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
>> 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 [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
# 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
== <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:
<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 =
= 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