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

Re: XBL Namespace uses the data: scheme

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 30 Jun 2006 16:33:23 -0400
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: www-tag@w3.org
Message-ID: <OF92918AD6.31A826C1-ON8525719D.006F51C2-8525719D.0070EBC8@lotus.com>

Hmm.  I really do appreciate the detailed feedback.  I say "hmm" because 
the draft was out for review for awhile, and as recorded in the minutes 
[1] the TAG at its recent F2F approved publication as a TAG finding, 
subject to a few specific revisions to be made.  It also happens that I 
will be out of email touch for most of the next two weeks, and can't 
effectively participate in any followup discussions until I get back.  So, 
I hope that other members of the TAG will in the meantime give some 
thought to which if any of your comments they believe merit revisions 
beyond those already requested.  I'll collect all that feedback in 
mid-July to decide what to do.

I don't have time to respond in detail to all the important points you 
raise, so let me just comment on a few of the simpler ones now, and leave 
the rest for later:

> The resource locator of the resource is poorly chosen

> It seems http://www.w3.org/2001/tag/doc/metaDataInURI-31 is intended
> to be used directly by people, yet it is not easy to understand (why
> "2001"? Why "doc"? Why "31"?) and consequently not suggestive of the
> resource actually named (too much noise to determine the signal).

These comments appear separately in your note, but they seem related. 
FWIW, I don't believe that such URIs are intended primarily for use by 
people, though some attention is paid to giving them orderly structure and 
making the segments of the hierarchy comprehensible.  Indeed, I've heard 
it asserted that of the URIs for which W3C is the authority, only 
www.w3.org and perhaps a few others are assigned with ease of recall by 
people and ease of typing as a primary goal.  My assumption is that the 
TAG's assignment pattern for its documents, which predates my tenure and 
is consistent with the W3C's overall policy, is aimed primarily for 
convenience of the assignment authority, I.e. for providing an orderly 
means of generating unique identifiers that are stable over a long period 
of time.  Yes, there are ways to do that while being even more obscure, 
but my assumption is that to the extent that words like "tag" are recorded 
in human-consumable form, that's a "nice to have" not a primary goal. 
Mostly documents like this finding are accessed through hyperlinks, IMO. 

I think you can only call these "poorly chosen" relative to some metric of 
goodness, and I suspect that there's disagreement about the metric in this 
case.  My inference is that ease of use by people was, intentionally, a 
secondary concern in assigning URIs to TAG documents.

> then incorrectly claims to make correct use of RFC 2119 terms

The constraint at [2]  says:

"Constraint: Web software MUST NOT depend on the correctness of metadata 
inferred from a URI, except as licensed by applicable standards and 
specifications."

Is that not making correct use of RFC 2119's MUST NOT?

> The first good practise is rather odd;

If you mean the one in section 2.2, we've agreed to drop the whole 
section.

As I say, I'll look for TAG feedback on your other comments after I get 
back.  Also, please be sure we're talking about the same version of the 
finding, the dated copy of which is at [3].  I had a bit of a suspicion 
that your reference to "schemes" in the first GPN might have somehow come 
from an older copy.

Thanks again for the comments.

Noah


[1] http://www.w3.org/2001/tag/2006/06/14-minutes.html#item01
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31#erroneous
[3] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Friday, 30 June 2006 20:33:37 GMT

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