RE: QA Tips: Make readable URIs

> 
> * Dominique Hazal-Massieux wrote:
> >Sorry for the bad turn-around... I have posted your document 
> as draft 
> >tip on the tips list: http://www.w3.org/2001/06tips/readable-uri.html
> >http://www.w3.org/2001/06tips/
> 
> Publishing the tip at 
> http://www.w3.org/2001/06tips/readable-uri.html is 
> ridiculous. I suggest to read 
> http://www.useit.com/alertbox/990321.html
> A good URI for the document would be e.g.
> 
>   http://www.w3.org/QA/tips/readable-uris
> 
> The current URI even violates 
> <http://www.w3.org/Provider/Style/URI>...
> 
> >- one of the principle behind the design of the URIs is that 
> they are 
> >opaque, which means that nothing/nobody should infer 
> anything from the 
> >characters used in the URI; this should be reminded at the 
> very top of 
> >the tip, and maybe the title of the tip should be changed to 
> make that 
> >clearer.
> 
> I disagree. URIs are an important part of the web site user 
> interface, they are commonly recognized and used by users of 
> the web site and these users expect URIs to be designed and 
> to behave in certain ways.

I also disagre with the statement "URIs .. are opaque, which means that
nothing/nobody should infer 
 anything ..."  I think this is too strong.

I would say that ideally URIs should not be based on the technology used
to serve the resources (i.e. no .asp, ,jsp, .php etc. as file
extensions) and ideally should be independent of the file format (e.g.
use foo rather than foo.html and bar ratehr than bar.gif or bar.png).
However on *can* infer something from other parts, such as /QA/tips/).

See <http://www.ariadne.ac.uk/issue31/web-focus/>.

Brian
 
> >"When a URI has to be advertized through a medium that 
> doesn't easily 
> >support following hypertext links (e.g. a URI on paper or in 
> some email 
> >clients), it's much easier for the user to have to type a 
> readable URIs 
> >rather than a unreadable one."
> 
> URIs are not about advertisement by content providers, they 
> are about users who interact with a web site. The number of 
> URIs for which it would be unreasonable to expect users to 
> talk about the resource in an email or type it directly into 
> the address bar of their web browser is close to zero, so in 
> practise there is no "when" or "have to" involved here.
> 
> >I simply don't agree on the recommendation of using directories 
> >generally speaking. The organisation of a Web site is really too 
> >dependent on the server configuration, the information architecture, 
> >the publication system to make such a general recommendation.
> 
> This is irrelevant for URI or site structure design. This is 
> user interface design which considers only the user and his 
> expecations and not internal organization. Usable URIs 
> reflect the site structure and are hackable and most of the 
> time this can be achieved by using path components. 
> 
> >I like the part about language negotiation, although it 
> would be nice 
> >to have this notion appear in the text.
> 
> Using language negotiation is good, using /index.html.no 
> instead of /no/index.html as the tip suggests probably is 
> not. IMO, quite the opposite should be recommended. Two 
> simple problems: first, you want a search engine to index all 
> your localized pages, how do you do it? HTTP provides no 
> means to query for all alternates so you need specific links 
> to consider all of them and visitors would rather get to 
> /index.html.no instead of /index.html which is intended. 
> Second, even though a user has configured his browser to 
> prefer german over english, he wants for some reason to read 
> the web site in english. How does he switch the language for 
> the current site without changing his browser configuration? 
> Not possible using /index.html.no but easy using 
> /no/index.html. The tip also contradicts another tip, "enable 
> localized directory names" as you cannot use language 
> negotiation the way suggested if the URIs are different.
> 
>

Received on Friday, 19 September 2003 04:49:32 UTC