You're certainly welcome to talk about it on this list, as long as it
doesn't get too far afield. Profiles themselves are very near-and-
dear to microformats, and definitely on topic.
I myself know virtually nothing about HTTP internals, so I'm not
likely to contribute much. :-)
-- Ernie P.
On Apr 12, 2006, at 3:00 PM, Mark Nottingham wrote:
For other reasons, I've been thinking of putting together an I-D to
revive the Link HTTP header, along with a separate header to
capture the URI(s) of the profile(s) in effect for the content.
Interested?
On 2006/04/12, at 2:55 PM, Dr. Ernie Prabhakar wrote:
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)
== <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 =
* 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"?
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
microformats-rest mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-rest
