Re: [URN] URI documents -- "# fragment"

"John C. Mallery" <jcma@ai.mit.edu> wrote:
>Might be worth noting that #fragment is utterly bogus.  It is a positional
>identifier and cannot be recycled for server-side fragments because it has
>been consumed by legacy web applications.

	I perhaps should not have included that paragraph under
circumstances in which I have only occassional access to this account
and cannot participate in an extended discussion about the matter,
but since I'm logged in again now...

	I do not see how these references to "bogus" and "legacy web
applications" serve any useful purpose in the "evolution" of the Web.
The #fragment was specified as a way of providing instructions to a
client via a URI-reference, is positional, and is not considered part
of the URI.  I realize that there are only so many US-ASCII characters
which can be used as delims in a platform-independent manner, and most
if not all of them are "taken" for something or other at this point.
If you which to support server-side instructions, then it presumeably
must be via something to the left of any crosshash in an overall
URI-reference.  The '?' and '@' in URLs in effect delimit instructions
to the server, and perhaps could be used for instructions sets in URNs.


>The only relevance for URIs is that applications expecting to move an
>identifier through HTTP URLs (e.g, URN resolution) must quote #. This
                    ????
>is why PDI switched from # to $.

	Fragment instructions apply to media types (presently defined
and widely implemented fragment instructions apply to text/html), not
to schemes, i.e., not specifically to HTTP.


>It is unwise to reify legacy design decisions in all possible future
>identifiers.  Such over encumbering of URIs reduces degrees of freedoms
>needed for evolution and shortens the longevity of any URI framework,
>ie hastening the time when all identifiers must be discarded and one
>must start from scratch.

	The concern is that existing, interoperable implementations
are not broken needlessly in new IETF specs.  Terminology such as
"reify legacy design decisions" is stone throwing, and that often
leads to breakage.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Monday, 26 January 1998 18:05:44 UTC