Re: draft-daviel-metadata-link-00.txt

>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

Received on Wednesday, 14 May 1997 19:05:18 UTC