New editor's draft of TAG Finding on "The Use of Metadata In URIs"

I am pleased to announce the availability of a new draft of a TAG finding 
on "The Use of Metadata In URIs" [1,2].  At its June 2006 F2F meeting in 
Amherst, MA, the TAG voted "to accept 
http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609 contingent on 
Noah finishing his TODO list to the satisfaction of Ed Rice."  This draft 
is intended to address the issues raised by Ed [3] and also those received 
later from Stuart Williams (see Stuart's note at [4] and my response at 
[5]).  During this period, comments were also received from Bjoern 
Hoehrmann (Bjoern's note is at[6], response at [7]).  Although I did not 
make changes to the draft specifically in response to Bjoern's comments, 
Bjoern was among those who had problems with the former section 2.2, and 
that section has indeed been removed.   Bjoern was also concerned with the 
URI of the finding itself.  As I suggested in [7], the finding's URI is 
consistent with the pattern established for other TAG findings and with 
the W3C's overall URI assignment policy.  While I can understand the 
arguments pro and con for changing those policies, doing so is well beyond 
the scope of this effort.  So, I have continued to use the established 
pattern in naming the latest drafts.

Since the TAG in June gave it's clearance for publication as a finding, 
pending resolution of Ed's concerns, I expect that this will become a 
formal finding once Ed gives his assent.  In any case, I plan to wait at 
least for a week, to give a chance for others in the community to do a 
final review too.  If you have concerns, please send them along ASAP.  A 
reasonably complete log of changes made since the previous draft is 
attached as an appendix to this note.  Thank you!

Noah

[1] http://www.w3.org/2001/tag/doc/metaDataInURI-31
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061016.html
[3] http://lists.w3.org/Archives/Public/www-tag/2006Jun/0041.html
[4] http://lists.w3.org/Archives/Public/www-tag/2006Jul/0026.html
[5] 
http://lists.w3.org/Archives/Public/www-archive/2006Jul/att-0009/metaDataInURI-31-skw-ann.pdf
[6] http://lists.w3.org/Archives/Public/www-tag/2006Jun/0152.html
[7] http://lists.w3.org/Archives/Public/www-tag/2006Aug/0069.html


===================================
Changes Since the 9 June 2006 Draft
===================================

Suggested at the Amherst F2F :

* Section 2.1: Change "licensed" to "documented"  (DONE)

* Remove section 2.2 "avoid depending on metadata (DONE)

* F2F review suggested formatting was too heavyweight (Removed boxes 
around examples)

* F2F review suggested adding reference to AWWW.  I did that and also 
added an explicit link to the section on URI Opacity.  The text now reads 
"The TAG has earlier published a finding Authoritative Metadata 
[AUTHMETA], which explains how to determine correct metadata in cases 
where conflicting information has been provided. This finding is concerned 
with just one possible means of determining resource metadata, i.e. from 
the URI itself. The TAG publication [AWWW] discusses related issues under 
the heading of URI Opacity; this finding provides additional detail and 
guidance on the encoding of metadata into URIs, and on when it is or isn't 
appropriate to attempt to infer metadata from a URI."

* Change should not to SHOULD NOT in section 2.7 (DONE)

Here are Ed Rice's comments (see [3]) with dispositions:

* Intro; editorial comment.. I'd remove the 'for retrieval or for other 
operations'.  Just delete it :) (DONE)

* Section 2.2 bring up the point that you cannot assume a .jpeg is a 
.jpeg.  This is actually something I've never liked much.  In the days of 
spam/phishing people are starting to look at URL's to see if they're what 
is expected.  If a .jpeg extension is really an executable.. I see that as 
an issue.  Granted, this is outside the scope of your paper as our citing 
another reference, but I think it should be considered. (SECTION DELETED 
FOR OTHER REASONS.)

* In section 2.4 you say that if there is a page where the user enters the 
city, then its ok to use the inspected URI and create new software to 
build them.  I don't agree, this seems like it would still be guessing (at 
best).. The best practice would be to direct people to the page where they 
do the entry.  (I THINK THE REST OF THE TAG AGREED THIS IS OK, AND I 
PROPOSE TO LEAVE IT.)

* Section 2.5.. Editorial comment, seems odd to reference in the first 
line, the 'example above'.. Shouldn't each section largely stand alone? 
(THAT'S NOW SECTION 2.4.  REPLACED THE OFFENDING "EXAMPLE ABOVE" WITH 
EXPLICIT HYPERLINK TO SECTION 2.3)

* Section 2.5 the 'good practice' seems to conflict with the section.2 (as 
noted above).. (I DON'T AGREE THAT THERE WAS A CONFLICT, BUT THE FORMER 
SECTION 2.2 IS GONE ANYWAY.  NO CHANGE MADE.)

* Your conclusion seems to also imply that if you don't want (or expect) 
the user to 'read' the URL, then its at least ok (and maybe expected) that 
you use larger or more complex URI's that cannot be easily guessed. YES

Two changes were made in response to the comments from Stuart Williams 
([4,5]):

* Reworded introduction now says: "The first question is primarily of 
concern to URI assignment authorities, who must choose a suitable URI for 
each resource that they control. The other questions are focused on people 
and software making use of URIs, whether at the resource authority or 
elsewhere.   Of course, the questions are related, insofar is one reason 
for an authority to encode metadata is for the benefit of resource users."

* Section 2.2:  Changed to "Bob has seen an advertisement listing just the 
Chicago URI, and that is the only one that the URI authority has warranted 
will be a useful weather report."

Miscellaneous changes

The status of document section has been updated and now includes:  "The 
previous draft of this finding was discussed at the TAG face-to-face 
meeting of 14 June 2006, and this draft is intended to address the set of 
changes agreed at that meeting, as well as other issues raised in emails 
since then. The TAG resolved at the meeting to publish the result as a 
finding without further formal review. Thus it is anticipated that this 
draft will shortly be superseded by a very similar one which will be 
labeled as an agreed TAG finding."


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Monday, 18 September 2006 18:09:41 UTC