- From: Victor Engmark <Victor.Engmark@cern.ch>
- Date: Wed, 18 Aug 2004 11:03:33 +0200
- To: "olivier Thereaux" <ot@w3.org>
- Cc: <www-qa@w3.org>
> -----Original Message----- > From: olivier Thereaux [mailto:ot@w3.org] > Sent: Tuesday, August 17, 2004 4:46 AM > To: Victor Engmark > Cc: www-qa@w3.org > Subject: 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. Sorry about that, I'll clarify (this is not guaranteed to be correct, of course): "to try and keep URIs simple* -> "to try TO keep URIs simple" "technology-specifics" -> "technology specifics" > > - 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. Take the URL http://www.w3.org/QA/2004/08/readable-uri: It tells me that the protocol is HTTP, that it is a web page (for somebody not familiar with the web, w3.org might not look like the same), that W3 is an organization, and that the readable-uri page was published by the QA group in August 2004. > 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] AFAIK, URLs are a subset of URIs, with the differences that: - a URL is not necessarily an identifier, while a URI is, and - a URL points to data about something, while a URI doesn't have to point to the information. > [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". This seems to me to indicate that URLs like abc://def.ghi.jkl/12345 are preferable to http://www.w3.org/QA/2004/08/readable-uri. The first URL is opaque, the second is most definitely not. Could someone please clarify if this really the intent of the recommendation of having opaque URIs? I always thought of it as more of a warning sign: Do not put more information into URIs than strictly necessary, and leave out all technical details. > > - 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§ion=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? In this line of thought, perhaps it could be beneficial to collect the tips into more of a book, groupable using either theme (usability, speed of development, graphical) or technology (URIs, XHTML, validation, internationalization). This might be too much work, though. -- Victor Engmark
Received on Wednesday, 18 August 2004 15:00:51 UTC