Re: draft-daviel-metadata-link-00.txt
Jim Whitehead (ejw@ics.uci.edu)
Wed, 14 May 1997 19:04:21 -0700
>I have submitted
>http://vancouver-webpages.com/ml/draft-daviel-metadata-link-00.txt
>which suggests a code of practice using Link relationships with existing
>HTTP/1.0 servers and HTML 2.0 parsers to associate metadata
>with non-HTML resources. I have tried to address most of the issues
>raised (apart from "forget it; it'll be in HTTP/1.2").
>
>Basically, the concept is to include a Link header
> Link: <http://some.org/some-jpg.html>; rel="META" ; scheme="DC"
>in response to a request for a resource which cannot embed metadata
>with an optional reverse link
> Link: <http://some.org/some.jpg; rev="META" ; scheme="DC"
>from the metadata to the resource.
Well, I just scanned through this, and I was puzzled to see a proposal that
was extremely similar to the Link header proposal in Section 19.6.2.4 of
RFC 2068 without discussing why it was necessary to replace it. As near as
I can tell, you can use the BNF productions in this section to accomodate
your needs -- scheme becomes a "link-extension".
> Multiple Schemes - It may be desirable to register a resource in
> more than one scheme. I suggest using an explicit scheme tag.
> Another possibility is to append the scheme to the relationship,
> e.g. REL="META.DC" Specifying an explicit scheme may break
> current HTML DTD.
While the addition of a scheme A/V pair to the link is interesting, it does
raise the question of who maintains the schema namespace, and also the
"rel" and "rev" namespace. IANA could, but this creates a centrally
managed namespace. Using URIs for schema names creates a decentralized
namespace, but raises questions about the longevity of the schema names.
Some nits:
In your BNF productions in section 2.1 I think you want to replace "meta"
with quoted-string.
- Jim