Hi Ashok,
On 13/01/2009, at 8:32 AM, ashok malhotra wrote:
The TAG asked me to review the site-meta draft:
http://tools.ietf.org/html/draft-nottingham-site-meta-00
Comments below.
These are my personal comments and have not been reviewed by the
TAG. So, it is possible that some TAG members may disagree with them
and/or have additional comments.
Minor Comments
1. I think you realize that the use of site-meta as a suffix to the
URI steals a portion of the address space available for URIs and may
be in conflict with existing URIs that use ‘site-meta’ at the end. I
presume you have come to terms with this as a necessary evil.
Yes.
2. It takes 2 requests to access a piece of metadata. This, too, I
presume you have come to terms with.
Yes. The hope is that the cost will be reduced as such a mechanism is
used more, because of caching.
3. The text says that “Each "meta" element … MUST have a "rel"
attribute containing a link relation.” However, the third meta
child in the example does not have a ‘rel’ attribute. Is this a typo?
<meta type="text/example">
foo = bar
baz = bat
</meta>
Yes; thanks.
4. In the above example, I presume “foo = bar baz = bat” is the
content of the metadata. Is this meant to be free text or XML? A
few words of explanation and/or a realistic example would be helpful.
Will do. I expect the format to change pretty radically in the next
revision (to a header-like textual one), so this may not be relevant
any more.
More Serious Comments
5. The <metadata> element contains <meta> children that contain
information about individual pieces of metadata. But metadata about
what? Is this metadata for the site as a whole or for some URI
contained on the site? Specifically, what is the subject of the
“rel” attribute?
There's been some pretty detailed discussion of that recently on the apps-disc...@ietf.org
list; the upshot at this point is that the scope is by default
(host, port), but specific uses of the mechanism can define other
scopes (e.g., FooPolicy can declare that to find its metadata for an
email address in example.org, one would look at http://example.org/site-meta
and http://www.example.org/site-meta, first match wins).
6. Since we are suggesting two mechanisms for accessing metadata:
Link Header and site-meta, it seems to me that we need to say
something about the relationship between these mechanisms. Do we
need both? What are the usecases? Can a website support both
mechanisms? I see no reason why it should not. If site-meta is
about the site as a whole, how can I get metadata about individual
URIs on the site? Do I use the link header mechanism for this?
I'm very shy of defining a closed world model of metdata on the Web,
or for that matter anything that claims to be "the" model for metadata
on the Web. This proposal will co-exist with the Link header in much
the same way that it will with any other HTTP header, media type, or
other component of the Web.
7. If a website supports both the Link Header and the site-meta
mechanisms, then the data obtained from using these two mechanisms
must be consistent. As it stands, the structure of the <meta>
element and a Link Header entry are a bit different. Should these
be aligned?
See above.
Cheers,