[uf-discuss] "Lightweight Data Access Services" and Well Designed Urls

Tue Oct 17 18:38:42 PDT 2006

Le 17 oct. 2006 à 17:20, Mike Schinkel a écrit :
> Many thanks for commenting.
>
>>> BUT be careful of Well Known Location issues.
>
> Can you give me examples? I googled "Well Known Location" and  
> didn't find
> anything that seemed relevent.

http://example.org/robots.txt
http://example.org/favicon.ico
http://example.org/p3p/

All of these tend to reduces the freedom of users, plus do not make  
them independent. For example, in the case of robots.txt, that some  
search engines ignore (sigh), you can't do things like

http://farm.example.org/weblogA/robots.txt
http://farm.example.org/weblogB/robots.txt

For favicon.ico you can add a link to your header in your HTML page,  
but still some user agents will stupidly make a request to http:// 
example.org/favicon.ico

    <link rel="icon"
       type="image/png"
       href="/somewhere/myicon.png" />

    http://www.w3.org/2005/10/howto-favicon

>>> Trying to standardize URLs would be very bad by limiting the  
>>> choices of
> users.
>
> I don't think I'm trying to standardize URLs per se. I'm instead  
> trying to
> collect up, codify, and recommend patterns and practices.

Yes but you have to make a BIG warning about bad practices too.  
Because people will run into the illusion of practical well-known  
locations.

>
> Since you commented, did you read this first?
> http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx

Yes I did :) It is mostly what

   - Cool URIs don't change
     http://www.w3.org/Provider/Style/URI
   - CHIPs - Common HTTP Implementation Problems
     http://www.w3.org/TR/chips/
   - Web Architecture
     http://www.w3.org/TR/webarch/
   - Managing URIs
     http://www.w3.org/QA/Tips/uri-manage
   - Choose URIs wisely
     http://www.w3.org/QA/Tips/uri-choose

> As an aside, I think limiting choice can be good (if you have ever  
> eaten at
> TGI Fridays, I'm sure you will relate to that comment!)

Limiting choices in a service might be good,
limiting choices in my ability of cooking is bad.

> Too much choice
> creates chaos and allows inexperienced people to make really sub- 
> optimal
> choices for no other reason than happenstance. Best practices call  
> out where
> the pitfalls are, and how best to avoid them.  If all choice was  
> good all
> the time there would never be any use for Best Practices for anything,
> right?

Best practices are good.

> I think the things I'm thinking about as best practices are not of  
> the same
> as the types you are talking about. I planning to codify those  
> things that
> will make it easier for users to work with URLs;

What do you mean by "easier for users to work with URLs"

btw not sure the discussion belongs here but more on public- 
evangelist at w3.org

> * Once published, don't move the content to another URL

	web architecture

> * But if you move it, always leave a 301 or 302 redirect when you  
> move a URL

	web architecture

> * Don't change the meaning of content at a published URL (with  
> caveats, to
> be later discussed)

	web architecture

> * Ideally don't use extensions for (X)HTML content.

	cool uris
	CHIPs

> * If you must use an extension for (X)HTML content, use either .HTM  
> or .HTML

	or .xhtml for XHTML it can help for mime-type management for example.

> * Extensions on URLs should define the content, not the technology  
> that was
> used to create the content (i.e. .HTML not .ASPX, .JPG not .PHP, etc.)

	cool URIs

> * When you peel off a subdirectory from a URL it should return a  
> valid and
> appropriate .HTML page

	Why?
	Here you make the confusion between a URL (resource) and a file  
(HTML document, image, etc.)

> * Avoid using "magic numbers" in URLs whenever possible (i.e. use
> www.mysite.com/cars/ not www.mysite.com/5/)

	Why?

> * A URL with a trailing slash should equal a URL w/o a trailing slash.
> (i.e. www.mysite.com/foo should be the same as www.mysite.com/foo/)

	Why?
	And opposite to what you said about extension and not extension

	http://example.org/toto
	http://example.org/toto.html
	http://example.org/toto.html.fr
	http://example.org/toto/
	http://example.org/toto.svg

> * Organize major site divisions by subdomain (I need to put a lot more
> thought into this one about when and when not to)

	why?
	and I would say no.
	A website is an information space not buildings. It moves in terms  
of information structure. if you tie the organization of your  
information to the logical structure of a path, you make it difficult  
to manage on a long term.
	Date spaces are one way of organizing data.
	Here there's a misunderstanding between the navigation of  
information paradigm and the information space paradigm.

> * Sitemaps and Website URL structures should have a very tight  
> coorelation.

	Could you explain a bit more?

> * For new websites and website redesign, design your URL structure  
> as one of
> the first steps.

	contradictory with what is said just above. in the sense that it is  
the common problems people have redesigning
	When the content is being tied to the structure of the URLs when the  
info-structure changes they have problems moving stuff and they do  
not create the redirect.

> BTW, some of the above it is VERY DIFFICULT to do in Microsoft IIS  
> (until
> version 7.0) and many commercial web applications and content  
> management
> systems) do a horrific job related to providing clean URLs  (i.e.  
> Vignette,
> DotNetNuke, etc.).

I do not like as well URIs of Vignette but more because they are very  
long than meaningful. I try to not remember URIs I'm using, there are  
tools for that: bookmarking sites/features and search engines.

Readability of an URI is an illusion. Think about QR code or IRI (ex:  
chinese characters in an URI)

>>> Microformats have a "poor man namespace" mechanism which is the  
>>> profile
> in the head. It helps people using the same class names to be free  
> to use
> them without the same semantic (with the hope that search engines,  
> do not
> index microformats not properly identified by the profile.)
>
> I'm not seeing how this relates to URL design per se.
>
> Also, are you considering Microformats only valuable for search  
> engines?

For search engines, for marketing profilers, for TIA (governmental  
agencies): 100%
For users: 5% useful, 95% dangerous.
(long off topic debate possible here about the notion of opacity and  
privacy)

>>> Do not confuse Web Architecture with URLs. That's the part which  
>>> is not
> understood from REST Web architecture style.
>
> I'm not sure I can confuse them yet because I don't really know  
> what "Web
> Architecture" is other than a highly abstract term used to describe  
> the
> collective technology architecture for all that is the web. Is is mean
> something else to which I am just ignorant?

See the references above.

>
>>> I encourage your to read this excellent series of posts by Joe  
>>> Gregorio
> http://www.oreillynet.com/tags.csp?tag=rest
>
> I reviewed these but didn't find anything that was new to me as  
> I've been
> collecting articles about REST and about building APIs. I include  
> them so
> you can see my influences:
>
> About REST for Web Services
> *	Building Web Services the REST Way
> <http://www.xfront.com/REST-Web-Services.html>
> *	REST: Simplicity in Web Services design
> <http://searchwebservices.techtarget.com/tip/ 
> 0,289483,sid26_gci1148486,00.ht
> ml>
> *	Representational State Transfer (REST)
> <http://en.wikipedia.org/wiki/Representational_State_Transfer>  at  
> Wikipedia
> orld <http://www.infoworld.com/>

REST is an architecture style. It is not related to URL design :)
REST is about the stateless nature of HTTP and the right usage of  
semantics of HTTP verbs.

> I'm anxious to know your thoughts based on my clarification.  Also,  
> would
> there be sufficient interest for me to start a list now, and invite  
> anyone
> interested to come on over?  I'll need 5-10 interested parties  
> otherwise it
> won't be time yet.

As I said there are very interesting things about your list, but  
maybe the list public-evangelist at w3.org is more appropriate for this.

Best

-- 
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
   QA Weblog - http://www.w3.org/QA/
      *** Be Strict To Be Cool ***