W3C home > Mailing lists > Public > www-tag@w3.org > February 2006

Re: [metadataInURI-31] A guide to where we stand on issue metadataInURI-31

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 24 Feb 2006 21:28:02 -0500
To: Mark Nottingham <mnot@yahoo-inc.com>
Cc: "Stuart Williams" <skw@hp.com>, www-tag@w3.org
Message-ID: <OF1EC40584.D7D6E5FE-ON85257120.000D2FA6-85257120.000D8E09@lotus.com>

Mark Nottingham writes:

> [nit] I'd rephrase this slightly to reflect that URIs *always* encode 
> metadata for private purposes (e.g., where to find the file / what 
> code to dispatch to).

I think that's a bit strong.  Consider a uuid: scheme URI.  I would say 
that it encodes metadata for private purpose only in the sense that you 
can tell the scheme name, and you can do literal equality testing to see 
whether two strings are the same URI.  Except in that rather sterile 
sense, I claim it encodes no "metadata for private purposes" (You could in 
many cases crack the UUID to get a MAC address, but for practical purposes 
they are treated as opaque.)  So, I think "always" is too strong, and 
interestingly so.

> I think that it's just as important to make this point (i.e., on 
> equal standing with those you put forth): "Authorities MAY 
> communicate information about the structure of their URIs (in other 
> words, instructions of how to extract metadata from them) for use by 
> observers."
> 
> Doing so is very useful and common, and people reading the opacity 
> documentation often conflate it with unhinted inference (which *is* 
> bad).

I agree, though with the caveat that any consuming software the depends on 
knowledge of such structure is likely to be less general than software 
that either treats URIs as opaque, or that extracts only metadata covered 
by very widely deployed specs (e.g. extracting the scheme or hiearchy 
based on RFC 3986).

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Saturday, 25 February 2006 02:28:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:38 GMT