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

Re: fragment prose proposal

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 11 Mar 2004 14:18:58 +0200
Message-Id: <45BFA11F-7356-11D8-83FC-000A95EAFCEA@nokia.com>
To: uri@w3.org

I don't in any way disagree with what you write below or Larry's

I also don't see how it contradicts my statement that fragids
force one into the domain of document retrieval since no matter
how you model it, you cannot get from a URIref with fragid to
a representation of the secondary resource without *first*
obtaining a representation of the primary resource.


On Mar 11, 2004, at 07:14, ext Adam M. Costello BOGUS address, see 
signature wrote:

> Patrick Stickler <patrick.stickler@nokia.com> wrote:
>> URIrefs with fragids are "second class" web URIs because they force
>> one into the domain of "document retrieval" simply to interpret them.
> URIs identify resources, so there must be a conceptual function g that
> maps URIs to resources.  We can impose a constraint on that function:
>     g must be separable into g1 and g2 such that
>     for all URIs of the form scheme:stuff#frag
>     g(scheme,stuff,frag) = g2(g1(scheme,stuff),frag)
> In other words,
>       primary resource r1 = g1(scheme,stuff)
>     secondary resource r2 = g2(r1,frag) = g(scheme,stuff,frag)
> There is no need to talk about retrieval or representation in order
> to express this separability constraint.  The key is that g1 does
> not depend on frag, and g2 depends on r1 itself, not on the URI used
> to identify r1 (there might be several URIs that identify r1 using
> different schemes).  [Concrete examples involving retrieval and
> representation are still helpful for building intuition.]
> This is just a formal restatement of Larry Masinter's succint "the
> important bit is that the fragment identifier is not used in the
> scheme-specific processing of the URI."
> http://www.nicemice.net/amc/


Patrick Stickler
Nokia, Finland
Received on Thursday, 11 March 2004 07:19:34 UTC

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