relProperty Re: [uf-rest] Roy Fielding on WebDAV and PROPs
zen at zenpsycho.com
Wed Apr 12 18:50:46 PDT 2006
Thank you Ernie, this is indeed making a lot more sense to me now.
Maybe someday I may be able to contribute intelligently to this
discourse. I have a couple of responses to your wiki entry.
> = 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.
perhaps a couple of examples of what would amount to extrinsic
metadata wouldn't be too far afield, and serve to sharpen the focus
of the problem a bit more.
> = 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
I am in the process of trying to determine how much of this is
already accounted for, and dealt with in the RDF specification. I
can't say I fully understand RDF, but a lot of this is sounding
familiar from when I tried to understand it . From what I understand,
there are already mechanisms to link to RDF descriptions from inside
an HTML page. I think there might be URL schemes for RDF properties
already worked out as well. I'm not sure though. Since we're talking
about metadata, there needs to be some form of metadata format we're
dealing with. Perhaps it's RDF, or some theoretical mf style
equivalent (such as xmdp).
The part that I haven't seen is an *implementation* where properties
become readable/writable from within a simple URI schema.
> == <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.
Are you talking about listing each property seperately in their own
link statement? Or a link to a file describing the URI schema in use
for the properties of that page?
> = 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"?
issue 1: It depends on whether our metadata is going to be flat or
heirarchical I suppose. if it's the latter, semicolon may not be the
best choice for use in a URL schema, as it presents a number of
Issue 2: Problems like this can be avoided through simple precautions
and good programming practice. if necessary, guidelines for URL
parsing could be drafted. The thing to avoid is using unfiltered URL
text directly as an SQL query. It is untrustworthy data. Numerous
functions exist to deal with this sort of thing already. Security
problems happen when coders don't know this, or are too lazy to use
Issue 3: As mentioned above, it would probably be a good idea to see
how much overlap there is in RDF in dealing in this problem space.
Random Brainstorm: Since we're talking about giving URI's to
extrinsic metadata, is it crazy to think it would be useful to create
URI's for intrinsic /data/? That is to say, a server provided way to
deal directly with microformats. A little off topic yes, but here's
what I'm thinking:
Say for example this URI contains several hcards http://
It's possible to then provide a server switch to automatically turn
this page into rest service:
GET http://www.example.org/contactpage/hcard/01;fn //retrieve
fn prop from first hcard
GET http://www.example.org/contactpage/hcard/02/adr;locality //
retrieve a subproperty from second hcard.
POST http://www.example.org/contactpage/hcard/new //post
url encoded properties to build a new hcard and place on contactpage.
just as an example. but I think it's an idea with some potential,
even if it's a far off pipe dream.
More information about the microformats-rest