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

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.

Jonathan

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