W3C home > Mailing lists > Public > www-tag@w3.org > December 2008

Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

From: Jonathan Rees <jar@creativecommons.org>
Date: Sat, 6 Dec 2008 10:21:51 -0500
Cc: "Marcos Caceres" <marcosscaceres@gmail.com>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, "www-tag@w3.org" <www-tag@w3.org>, public-webapps <public-webapps@w3.org>, "public-pkg-uri-scheme-request@w3.org" <public-pkg-uri-scheme-request@w3.org>
Message-Id: <08D8F43D-9BF2-4C00-8F31-82AA98C7DCDB@creativecommons.org>
To: timeless@gmail.com

On Dec 6, 2008, at 9:58 AM, timeless wrote:

> On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees  
> <jar@creativecommons.org> wrote:
>> I hate to burst ignorantly into a discussion I know little about...  
>> but
>> that's what I'm going to do. Forgive me.
>> Regarding the creation of local URIs for use in APIs requiring  
>> URIs: I want
>> to consider, just as a what-if meant for clarification of  
>> requirements, the
>> use of the tag: URI scheme [1], which appears on first blush to be  
>> a good
>> fit.
>> Suppose that the desired suffix of the URI is to be zzz. The URI  
>> would look
>> like
>> tag:widgets-r-us.org,2008:8948372837/zzz
> i'm 99% certain this is in the minutes from the F2F, a WUA needs to be
> able to instantiate multiple discreet instances of a widget, and needs
> to be able to distinguish them. the instances need to be distinct.
> Whether distinct instances should be able to enumerate and connect is
> not currently decided but for future improvement the scheme shouldn't
> prohibit this.

OK, if you need to distinguish the instances, give each a different  
tag: URI. You could identify the instance using an entropy-generated  
bit string, and maintain a mapping from bit string to instance. Or, if  
you have some other way to designate an entity internally, such as  
process id + index into a table, you could put that information, or a  
hash of it, into the tag: URI, in combination with entropy or some  
other hash if you like. I hope it is clear that I'm not specifying a  
particular way to choose the tag: URI, as I can't because I don't know  
details of your requirements or architecture (sorry). The question  
was: Using tag: you can do just about anything you want in the way of  
exposing and/or hiding information (probably ten or twenty options  
here depending on what information and entropy feeds in and how/when/ 
whether it's hashed), so why not use tag: ?

In other words, if you think file: and http: have problems, the tag:  
URI scheme might provide a way out that does not require registering a  
new URI scheme. You still have a design problem (which you would have  
regardless), but at least you avoid one source of unpleasantness.

Received on Saturday, 6 December 2008 15:22:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:25 UTC