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

Hi Jonathan,

On Sat, Dec 6, 2008 at 3:21 PM, Jonathan Rees <jar@creativecommons.org> wrote:
>
> 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: ?
>

I certainly seems like a plausible solution, as it does, on the
surface, give us all the aspects that we require:

1. per-instance identity.
2. a path to files inside the package.
3. extensibility through using comas in the authority part (with the
ability to identify a domain of origin).
4. no conflict with existing implemented schemes in browsers.

However, reading [1] there are some outstanding issues wrt
compatibility with IRIs. It's unclear if that was resolved or not in
rfc4151.

> 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.

Agreed.

[1] http://www.taguri.org/
-- 
Marcos Caceres
http://datadriven.com.au

Received on Saturday, 6 December 2008 18:11:17 UTC