Larry Masinter wrote,
We're making up things about fragment identifiers. The
only existing ones are the ones that work with HTML,
and *those* certainly don't identify things with media
types.
<snip/>
I don't think fragments can or should have media
types. Content-type media types in MIME are for
identifying the application semantics intended by an
entire message body, and not for denoting anything
about the types of components of that body.
I agree that as things stand there are no media types
associated with fragments. But, for all that, I think
that Makoto's plea for something of this sort is
reasonable: where a resource is composite and has a
named constituent which could be treated as having
a media type distinct from that of it's enclosing
resource if taken in isolation, it'd be nice if that
media type were available.
One option to support this might be to extend media
types to allow for composite types (tho' I don't really
see how that could be made to work in practice). Another
option might be an HTTP extension: either a 'fragment'
GET, or more simply, a Fragment: request header. With
the latter we might replace,
GET /foo.xml#stylesheet HTTP/1.1
Host: foo.bar.com
with,
GET /foo.xml HTTP/1.1
Host: foo.bar.com
Fragment: stylesheet
and expect to get back an entity with with a
text/xml-xsl (or whatever it is) media type.
Hmm ... actully, looking at this, it strikes me that
there might be some overlap with the CONNEG stuff?
Cheers,
Miles
--
Miles Sabin Cromwell Media
Internet Systems Architect 5/6 Glenthorne Mews
+44 (0)181 410 2230 London, W6 0LJ
msabin(_at_)cromwellmedia(_dot_)co(_dot_)uk England