W3C home > Mailing lists > Public > uri@w3.org > February 2004

RE: Section 3.5. Passing fragment identifiers to other systems.

From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
Date: Wed, 25 Feb 2004 11:39:57 -0000
Message-ID: <54A600C436EA694581B93E4BD4D4788A0A60D6D1@elslonexc004.eslo.co.uk>
To: 'Larry Masinter' <LMM@acm.org>, "'Williams, Stuart'" <skw@hp.com>, "'Roy T. Fielding'" <fielding@gbiv.com>
Cc: uri@w3.org, 'Graham Klyne' <GK@NineByNine.org>

Hi Larry:

> I think fragment identifiers are only defined for use with retrieval,
> because the semantics of the fragment are (supposed to be, at least)
> defined by the media type of the retrieved result. With other 
> operations,
> there is no clear media type.

I wonder what this means with respect to the INFO URI scheme which defines a
fragment component as a regular part of the syntax,

	info-URI = info-scheme ":" info-identifier [ "#" fragment ] 

while at the same time asserting that INFO URIs are non-dereferenceable (and
hence there are no representations and no associated media types). In
discussing the use of fragment components in the INFO I-D we use language
which is closely aligned with that used in 2396bis (sect 3.5) to assert
that:

	The (unescaped) values for the "fragment" component identify
secondary 
      information assets with respect to the primary information asset 
      which is referenced by the "info-identifier".

It would seem that the historical use of fragment components has been to
provide an addressing mechanism into a resource representation following a
retrieval operation, as commonly used in HTTP requests. But in a pure
information context there may well be non-dereferenceable URIs such as INFO
which still have a clear need to articulate secondary resources with respect
to primary resources. So I do query what the role of media type is in these
contexts.

Tony
 
Received on Wednesday, 25 February 2004 06:40:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:07 UTC