Re: QA Tips: Make readable URIs

On Aug 4, 2004, at 20:56, Victor Engmark wrote:
>> 	http://www.w3.org/QA/2004/08/readable-uri
> This looks good. Still, IMHO it needs more work:
> - I found one grammatical error, so a quick check should be done.

Good catch. But Where is it?
The document passes spell check, but either my eyes or my english are 
not good enough to find the grammatical error you mention.

> - The language negotiation example URIs should contain a common postfix
> like ".html" or ".php" before the language, to disambigue the position
> of the placing and avoid users trying to serve an HTML file as "foo.en"

WEll, nothing stops them from serving an HTML file without .html file 
extension if they know how to configure their server. But I understand 
your point.

One question I am asking myself (and would like the opinions of www-qa 
readers) is whether the language suffix should be before or after
the file suffix. I've seen both used, but I have not seen a lot of 
arguments for one or the other. These days I tend to think that 
foo.en.html allows one to point at a language-specific instance of the 
resource while keeping the file suffix hidden, which I find rathe 
relegant, but maybe I forgot an obvious drawback.

> - I do not agree to the tip about making web addresses opaque. Perhaps
> the title should be changed to specify that the theme is URLs, not the
> more general URIs. URLs have always had, and probably will continue to
> have meaning.

That's where you'll have to quote relevant documentation if you want to 
convince me of your rather bold statement that URLs always had meaning. 
As far as I can tell, even though early-web-documents were 
soul-searching with regards to URIs/URLs, all post-1997 documents 
clearly state that URI=URL[1] (which makes the first part of your 
statement moot) and that these are opaque by design[2]

[1] http://www.w3.org/TR/uri-clarification/
[2] http://www.w3.org/DesignIssues/Axioms.html#opaque

I have actually been rather accommodating by using terms such as 
"supposed", "rather", "not necessarily". In practice, many people 
create URIs which are not opaque at all, but that does not change the 
opacity-by-design of URIs any more than the quantity of invalid 
"HTML4.01" pages change the HTML 4.01 specification.

Now, one could say that the design/specification is wrong, that 
HTML4.01 should really have marquee (or whatever tag/construct you 
like) and that URIs should be meaningful, but I hope we all agree this 
is way, way beyond the scope of a "QA Tip".


> - The "Why readable URIs" section should contain descriptive examples.
> Try to find those which might at first sight look easy to implement
> (http://fishing.com/fish.php?chapter=1&section=3), and which can be 
> much
> more easily read if constructed differently
> (http://fishing.com/sea/rods/).

I'm all for examples in general. I am, however, concerned that the tip 
is rather long already. A W3C Note benefits from a lot of examples. The 
constraints of a "quick tip" make things a little harder. Do you think 
examples are absolutely necessary here for the comprehension of the 
ideas?

> - The text "Content negotiation" should link either to the "Further
> reading" section or directly to some resource explaining it.

Agreed, definitely. I am adding a few resources in the "further 
reading" and linking to them.

> - The link between language negotiation and ISO 639 is not necessarily
> obvious to a new reader, and should be stated explicitly.

Agreed.

Thanks for all your comments and suggestions.
-- 
olivier