- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 31 Mar 2004 10:39:56 -0500
- To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Cc: olivier Thereaux <ot@w3.org>, Rajasekaran Deepak <deepakr@students.iiit.net>, www-qa@w3.org
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