[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MIME types and fragment identifiers in HTML and XML



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@xxxxxxxxxxxxxxxxxxx           England