Fw: registries associated with URI schemes

The attached note [1] from Erik Wilde to the URI mailing list may be of 
interest to the TAG community for several reasons, possibly including:

* It proposes a new URI scheme
* The URI scheme relates to geolocation, and thus has some indirect 
relationship to work on geolocation APIs, and perhaps thus also to 
associated policy issues
* The note specifically raises questions about extensibility of URI scheme 
specifications, and of registries to coordinate such extensions.

I think this is pertinent at least to our TAG ISSUE-50 (URNS & 
registries), and perhaps also to ISSUE-31 (metadata in URIs), and perhaps 
also to ISSUE-40 (URI construction good practice).

Noah

[1] http://lists.w3.org/Archives/Public/uri/2010Feb/0050.html
--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------




----- Forwarded by Noah Mendelsohn/Cambridge/IBM on 02/24/2010 11:54 AM 
-----


Erik Wilde <dret@berkeley.edu>
Sent by: uri-request@w3.org
02/23/2010 02:34 PM
 
        To:     URI <uri@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        registries associated with URI schemes


hello.

http://tools.ietf.org/html/draft-ietf-geopriv-geo-uri-04 is the most 
recent version of a proposed URI scheme for geolocation. this scheme 
establishes a new IANA registry for scheme parameters in general, as 
well as a specific sub-registry for coordinate reference systems (one 
pre-defined parameter) used for geolocation values. i have two general 
questions about this:

- in general, is there some guideline/policy on how extensibility and 
registries should be designed for URI schemes? the proposed scheme 
allows to dynamically create new sub-registries for parameters which 
take predefined values. this means that the proposed registry structure 
is actually fairly complex.

- specifically, the registry proposed in this draft contains information 
(the geolocation coordinate reference system) that maybe should be 
shared across technologies. the W3C geolocation API, for example, also 
uses a geolocation coordinate reference system. the proposed HTTP 
location protocol 
http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-16 
also uses a geolocation coordinate reference system. is there some 
guideline/policy that tries to avoid such a duplication of information? 
in this specific case, i think the way to go would be to have an ID for 
describing the geolocation concepts, and then have specific technologies 
(such as the URI scheme and the geolocation API) refer to that ID. this 
worked for languages and country codes, but maybe because there was an 
external entity (ISO) managing those lists? does the IETF have a process 
that helps to implement this design pattern without help from the outside?

generally speaking, registries are a good thing to keep things evolvable 
and extensible, but registry sprawl seems to be a problem. and since 
registries typically have no API, it is almost impossible to write code 
that uses registries in a meaningful way. API-enabled registries 
probably are no problem at all (the DNS is more or less that, i would 
argue), but API-less registries might make it hard to implement support 
for URI schemes using this kind of extensibility.

kind regards,

erik wilde   tel:+1-510-6432253 - fax:+1-510-6425814
        dret@berkeley.edu  -  http://dret.net/netdret
        UC Berkeley - School of Information (ISchool)

Received on Wednesday, 24 February 2010 16:59:42 UTC