W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

Re: "tdb" and "duri" URI schemes...

From: Nathan <nathan@webr3.org>
Date: Fri, 05 Nov 2010 00:12:05 +0000
Message-ID: <4CD34BD5.1070004@webr3.org>
To: Larry Masinter <masinter@adobe.com>
CC: Graham Klyne <GK-lists@ninebynine.org>, Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>
Larry Masinter wrote:
> If you want diffs:
> http://tools.ietf.org/rfcdiff/?url1=http://tools.ietf.org/id/draft-masinter-dated-uri-07.txt&url2=http://lists.w3.org/Archives/Public/www-tag/2010Nov/att-0025/duri.txt

Thanks :)

> I was convinced by the complexity argument that the <embeddedURI> should not
> allow an (encoded) fragment identifier, but I suppose I could go back and reconsider?

please do, cutting the fragments is a bit like saying you can't have a 
name which end in R.

I've been through a number of use-cases this evening, and in each case I 
keep coming back to the following:


Where URI is URI as per RFC3986, with optional query string, and 
optional fragment (encoded or not).

Where duri: is as defined

Where tdb: provides semantic indirection, and where <URI> can obviously 
be a duri: too.

This way it's both forwards and backwards compatible, and caters for 
every use case both seen and unseen.

   the thing described by <A>

   the resource that was identified by <A> as of 2010

   the thing described by the resource that was identified by <A> as of 2010

   the resource that was identified by the thing described by <A> as of 2010

duri provides temporal, tdb provides semantic indirection, if you want 
them both, use them both.

seems cleaner than the current mix of:


Received on Friday, 5 November 2010 00:13:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:08 UTC