Dan said:
> We can't rely on using type, since this is the mime type, not the
contents,
> the UA may not use that to determine what the uri points to.
Sorry, I still don't get it! ;-)
The HTTP "Content-Type" header uses MIME "media types"
14.17 Content-Type
The Content-Type entity-header field indicates the media type of the
entity-body sent to the recipient or, in the case of the HEAD method,
the media type that would have been sent had the request been a GET.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
And RFC 2046 says
The first document in this set, RFC 2045, defines a number of header
fields, including Content-Type. The Content-Type field is used to
specify the nature of the data in the body of a MIME entity, by
giving media type and subtype identifiers, and by providing auxiliary
information that may be required for certain media types. After the
type and subtype names, the remainder of the header field is simply a
set of parameters, specified in an attribute/value notation. The
ordering of parameters is not significant.
http://www.isi.edu/in-notes/rfc2046.txt
Also RFC 2045
The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user agent can
pick an appropriate agent or mechanism to present the data to the
user, or otherwise deal with the data in an appropriate manner. The
value in this field is called a media type.
HISTORICAL NOTE: The Content-Type header field was first defined in
RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one
that is largely compatible with the mechanism given here.
The Content-Type header field specifies the nature of the data in the
body of an entity by giving media type and subtype identifiers, and
by providing auxiliary information that may be required for certain
media types. After the media type and subtype names, the remainder
of the header field is simply a set of parameters, specified in an
attribute=value notation. The ordering of parameters is not
significant.
http://www.isi.edu/in-notes/rfc2045.txt
So given that there is a LOM/XML-specific media type (or a proposal for
one) it seems quite reasonable to use that media type to infer that the
data content is LOM metadata?
Or turning the question around, I can't see what other sort of content
other than LOM metadata in XML would be served with that MIME type.
(I guess I can see that you might want to expose LOM metadata in
multiple different formats using several different MIME types, but the
document doesn't address that case.)
Also, the value of the HTML rel attribute is supposed to describe the
relationship between the HTML doc and the target resource, _not_ the
type of the target resource
http://www.w3.org/TR/html401/struct/links.html#adef-rel
though I do recognise that that distinction gets a bit fuzzy in
practice. ;-)
Cheers
Pete
|