Re: Comments of the site-meta draft

Thanks Ashok, this is very helpful (and timely). Replies inline.


On 1/12/09 1:31 PM, "ashok malhotra" <ashok.malhotra@oracle.com> 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 OEsite-meta¹ at the end. I presume
> you have come to terms with this as a necessary evil.

Yes, we are trying to justify it by making the file format simple enough
that it can be used as a registration point for future "well known location"
needs and avoid any more such solutions.

Some alternatives considered were using a Link header in the response to the
domain root HTTP resource or DNS to point to the location of /site-meta but
we wanted something that was trivial to implement and did not require
changes to existing infrastructure or deployment.

> 2. It takes 2 requests to access a piece of metadata. This, too, I
> presume you have come to terms with.

The current draft allows for embedding of metadata directly in /site-meta
which will avoid the second redirect. However, I expect that feature to go
away with the switch to a text-based file format (something like a list of
Link headers).

> 3. The text says that ³Each "meta" element S MUST have a "rel" attribute
> containing a link relation.²
> However, the third meta child in the example does not have a OErel¹ attribute.
> Is this a typo?
>
> <meta type="text/example">
>
>   foo = bar
>
>   baz = bat
>
>   </meta>

I'll leave it to Mark to answer.

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

The idea is that the inner text is equal to the content of the linked
metadata. Embedding it saves one roundtrip. A realistic example would be to
embed the content of robots.txt inside a <meta> element. But I don't expect
this example to stay.

>  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?

The subject is the "web site". We are still discussing how to define this
entity but for me, this is an abstract resource which is not identifiable
using a URI. I also believe it is not specific to HTTP, but about the
authority name in general.

Many services today stick metadata information on the root HTTP resource of
a domain to provide metadata that is not specific about the root resource,
but the entire web site. According to HttpRange14 [1], the resource:
http://yahoo.com/ which returns a 200 is an informational resource. If it
returned a 303 it could have been considered an abstract resource about the
site. But it is incorrect to associate information about Yahoo!'s web site
with its root resource (home page).

My view is that links in /site-meta (which is really what each <meta>
element is) are between the abstract "web site" entity and the linked
resource. On the other hand, links on the root resource (via HTTP Link
header or HTML Link element) are specific to that resource.

I also think that metadata about this abstract entity is not limited to
HTTP, even if served over HTTP. This means I consider it valid for
/site-meta to include metadata (or links to) about other schemes such as
mailto and xmpp. It is up to each application to decide if they want to
consider that information authoritative or not.

I do not think there is a way to represent this abstract "web site" entity
with a URI.

>  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?
>
> 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?

Both of these are directly addressed by my draft [2] submitted Friday:
HTTP-based Resource Descriptor Discovery. The goal of the draft is to
provide a unified view on the relationship between Link elements, Link
headers, and Site-Meta as they relate to metadata discovery. It also extends
Site-Meta to include links for individual resources using templates.

Thanks!

EHL

[1] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
[2] http://tools.ietf.org/html/draft-hammer-discovery-00

Received on Tuesday, 13 January 2009 01:41:14 UTC