Re: Proposed Quality Tip -- URI Usability

At 12:52 PM +0100 3/31/04, Jeremy Carroll wrote:
>> On Mar 26, 2004, at 06:05, Rajasekaran Deepak wrote:
>> 
>>> A proposed quality tip, "URI Usability", is attached.
>>>
>>> <http://students.iiit.net/~deepakr/uri-usability/>
>> 
>
>
>Comments on tip:
>
>1) "URIs must normally not have extensions"
>goes against much practice ...
>(that's not disagreeing but wanting to see what others say)
>I wonder if stating it more in terms of benefits would be more effective.
>
>e.g.
>"On many servers, URIs include a file extension corresponding to the mime type, or a directory name indicating the language, however, it often works better to exclude the file extension and language from the URI and make better use of content negotiation."
>

Yes.  File type determination, like trust, is fraught with pragmatics.  Has
not been successfully isolated therefrom.

The claim "often works better" would have to be substantiated well, as it can also causes problems.

Hiding file type information violates the "DRUMS principle" of "be strict
in what you emit and loose in what you accept."

You might think that a page hyperlinking to another resource is setting up
the user agent to accept some representation of the other resource.  But
if the other resource is an HTML page or a GIF image, it is more strict
to let the user know in the reference what sort of a representation they
can expect.

Opacity in URIs is a source of brittleness, and not consistent with best
current practice.  Probably the same for relying on file-type negotiation
to work without a manual override loop.

Where we wound up in the current Architecture Document draft is not that
bad on this point:  User agents may pay attention to factors other than the
protocol-borne metadata in dispatching file handlers, but only on explicit
user request, not automatically out of the user's notice.

http://www.w3.org/TR/webarch/#authoritative-metadata

http://www.w3.org/2001/tag/doc/mime-respect.html

If a user encounters difficulty with a resource representation, they 
deserve a shot at browsing the available alternative representations
to see which *media instance* works best, or actually works, for them.
At this point policies in accept-headers are inferior to a review
of the media instances because there are lots of sources of trouble
and the authoritatively stated media type is not diagnostic, it may
not be correct or it may not be directly the source of the problem.

Al

>
>
>
>2) Natural Languages:
>"The extension must be as specific as possible"
>does not work well with RFC 3066 bis
>http://www.ietf.org/internet-drafts/draft-phillips-langtags-01.txt
>(note all the dates have the wrong year - it is a 2004 draft)
>
>Two issues:
>a) RFC 3066 bis says
>[[
>Use as precise a tag as possible, but no more specific than is
>       justified. For example, 'de' might suffice for tagging an email
>       written in German, while 'de-CH-1996' is probably unnecessarily
>       precise for such a task.
>]]
>
>(I suspect that similar text is in RFC 3066 which is the current best practice)
>
>b) RFC 3066 bis introduces productive use of script codes, in which case (nearly) all en-us text could be marked up en-latn-us to show that it is in Latin script. This tip would then suggest (in direct opposition to RFC 3066 bis), that en-latn-us should be used instead of en-us.
>
>I suggest that the wording should be changed to more accurately reflect RFC 3066, and RFC 3066 bis wording. (Or maybe we should comment on RFC 3066bis)
>
>
>
>Jeremy

Received on Wednesday, 31 March 2004 10:41:35 UTC