W3C home > Mailing lists > Public > www-tag@w3.org > August 2002

RE: 13 Aug Arch Doc available for review

From: Dan Connolly <connolly@w3.org>
Date: 14 Aug 2002 13:52:22 -0500
To: Stuart Williams <skw@hplb.hpl.hp.com>
Cc: "'Ian B. Jacobs'" <ij@w3.org>, www-tag@w3.org
Message-Id: <1029351142.19176.1221.camel@dirk>

On Wed, 2002-08-14 at 13:07, Williams, Stuart wrote:
[...]
> URI and URI References
> ----------------------
> 
> [skw-2002-08-14-02]
> 
> I am very wary of the attempt to redefine the terms URI at the end of
> section 1.1. I think the terms URI and URI reference have been a source of
> problems in the past and will likely be a source of problems to come. But
> IMO, the definition of TAG-URI = AbsoluteRFC2396URI+OptionalFragment will
> make this document almost unreadable to anyone with a deeply infixed notion
> of URI based on current conventional usage.

I think I can count the number of people that know that
	http://example#foo
isn't a URI on my fingers. OK, maybe I need my toes.
(Keep in mind most people have never even heard of a URI;
they hurl URLs around, or just talk about web
page addresses).

And I agree that the  $Date: 2002/08/13 20:19:49 $  draft
doesn't help much: it assumes that you've got your
head around RFC2396, and then throws you a curve-ball.

But there is, I think, a fairly simple and appealing
architectural view in which http://example#foo
is in the same class as http://example, but
../foo is in a very different class from
http://example#foo . Does this rendition of it appeal to you?

  introducing URIs [was: 13 Aug Arch Doc...]
  Dan Connolly (Tue, Aug 13 2002) 
  http://lists.w3.org/Archives/Public/www-tag/2002Aug/0138.html

[...]

> [skw-2002-08-14-03]
> 
> I am also very wary about asserting that the thing identified by
> URI+fragment is a resource (which is what happens once you accept the
> redefinition of URI). On one level I could live with it justified on the
> basis that anything with identity can be a resource (RFC 2396 says something
> like that). 
> 
> However, resources can have fragments,

Be careful with your quantifiers. To be clear, yes,

	There exists resources R and F such that F is a fragment of R.

but *not*

	For all resources R, there is a resource F such that
	F is a fragment of R.

let alone

	Given a URI I for a resource R, there exists a resource F
	and a URI J, computed from I alone, such that I identifies F
	and F is a fragment of R.

> and if I have a resource identified
> by the URIRef http://example.com/someResource#otherResource, how do I
> reference a fragment of that resource (assuming it has one)?

OK, assuming it has one, I can coin a new URI

  mid:2002-08-14.thismessage@w3.org#abc
	(pretend that's the MID for this message)

to refer to it.

> The URI syntax
> does not provide me a way to do that...

Depending on how you meant the quantifiers in
your sentence to work, either (a) yes, it does, see above,
or (b) no, it doesn't, but who cares?

> so maybe one heads off may be to map
> the name of this resource into some new URI scheme eg.
> resource:http://example.com/someResource?frag=otherResource so that it can
> now attract further fragment IDs. The particular design would need more care
> so that it would recurse nicely. But that feels like a horible kludge.
> 
> Anyway... bottom-line. On the TAG telcon, we did discuss distinguish between
> the sort of thing that a URI references and the sort of thing that a
> URI+fragId references. I think there was consensus (although I'm not sure we
> really tested it) that need distinguish terms for the referent...

I got the impression we were headed the other way.

> but I
> think it would be folly to use the term 'resource' to denote the sort of
> thing referenced by a URI+Frag since that is commonly held to be the sort of
> thing that is referenced by a URI.

Please take a look at my "introducing URIs" message to see
if it really looks like folly.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Wednesday, 14 August 2002 14:51:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:53 UTC