RE: fragment prose proposal

Might it be impertinent to suggest that these document represent a legacy
view on the function of fragment identifiers in URIs? 

The INFO case may be instructive wrt the roll of media types since there are
no representations that can be retrieved and hence, apparently, no media
type that can be associated with the fragment identifier (unless there be
some null media type).

Tony

ps/
Henceforth contactable at mailto:tony@tonyhammond.net.


> -----Original Message-----
> From: uri-request@w3.org [mailto:uri-request@w3.org]On Behalf 
> Of Graham
> Klyne
> Sent: 27 February 2004 10:48
> To: Al Gilman; uri@w3.org
> Subject: Re: fragment prose proposal
> 
> 
> 
> At 12:18 26/02/04 -0500, Al Gilman wrote:
> >>I also think that "A fragment's interpretation is in many 
> schemes allowed 
> >>to depend on the media type [RFC2046] ..." is plain 
> misleading, as it 
> >>suggests that fragment interpretation is some how related 
> to the URI 
> >>scheme (which I think is wrong).
> >
> >I got the impression that this is true, and constructively so,
> >in the 'info' scheme.
> >
> >Can you explain why they shouldn't be doing what they are doing?
> >
> >How is it 'wrong'?
> 
> [[
> The significance of the fragment identifier is a function of 
> the MIME type 
> of the object
> 
> This means that the fragment id is opaque for the rest of the 
> client code...
> ]]
> and:
> [[
> The fragment ID spec for a new MIME type should  be part of 
> the MIME type 
> registration process.
> ]]
> -- http://www.w3.org/DesignIssues/Fragment.html
> 
> To my mind, this excludes the signficance of a fragment depending on 
> the  URI scheme, except indirectly to the extent that the URI 
> scheme might 
> constrain the MIME type.
> 
> This position is echoed at:
>    http://www.w3.org/TR/2003/WD-webarch-20031209/#media-type-fragid
> 
> #g
> 
> 
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>

Received on Friday, 27 February 2004 08:54:32 UTC