[uf-discuss] "Lightweight Data Access Services" and Well
DesignedUrls
Mike Schinkel
mikeschinkel at gmail.com
Wed Oct 18 13:41:29 PDT 2006
Klaus:
Thanks again for your very detailed reply.
>>>> 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/
Ah. Thanks for the examples. I'm aware of them, but I didn't realize that's
what you meant when you mentioned "Well Known Locations."
Well, rest assured that none of what I am currently envisioning for this
initiative includes any plans to recommend any new well known locations. As
I see it, those are domain-specific and as such not part of my envisioned
mission.
>> 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
What a pisser! (Seriously)
>> 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.
Ahhhh! I think I hear someone volunteering to join the team and help spread
the word about certain Worst Practices, no? ;-)
>>
>> 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
Well I'm glad I'm not too far off base! :) Note I referenced "Cool URIs
don't change" in my blog post.
>>>> 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.
As that was just my off-the-cuff remark, it sounds like a debate to be had
later when we are talking specifics instead of abstracts! :)
>>>> 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"
How about I postpone that answer? I feel the need to study prior art and
collect my thoughts before I publicly state things which I might later
prefer to retract! :)
>> btw not sure the discussion belongs here but more on public-
evangelist at w3.org
I agree. I started here because I saw synergy between URLs and Microformats
as a method to access data in a lightweight manner that only requires HTML
pages be marked up with the Microformats. As I see you are a co-chair of
QAIG I'd be happy to move the discussion there if you approve. Can you
suggest what information I should provide in my first post to the group?
I'm not going to copy the comments and questions you made on my points
because I think this is not the place to continue that discussion. How
about on the wiki? I've posted the list I sent you here:
http://wiki.welldesignedurls.org/Principles and then, if you will, please
create an account and a user page and then add your same comments here:
http://wiki.welldesignedurls.org/Talk:Principles (I know it's a lot to ask
for someone in your position, but I wanted your comments to be added by you,
not from me.)
I'll look into getting a mailing list for the initiative when it's not
2:30am :-)
However, I did start setting up the blog tonight. I installed WordPress at
http://blog.welldesignedurls.org and plan to flesh out each Pattern/Best
Practice via a post on the blog. I'll also offer an account on that blog for
people who end up participating a lot in the initiative.
>> Readability of an URI is an illusion. Think about QR code or IRI (ex:
>> chinese characters in an URI)
But IMO it is an important illusion. As Roy T. Fielding said[1]:
... but the social network-effect of the Web is enhanced by
meaningful URI.
In general, sites that give meaningful URI are used more often.
>> For users: 5% useful, 95% dangerous.
Although I would like for you to explain this in detail, it needs to be
elsewhere. Still, I'm 99% certain it will be an assertion that I disagree
with. I have seen too much anecdotal evidence that well designed URLs are
beneficial. I think some of the early ideas about URLs not being useful and
ideally being hidden have been proven to be shortsighted. I think the key
problems currently are:
1.) Lack of a catalyst (like this initiative can become)
2.) Lack of user education (like this initiative strives to provide)
3.) Lack of developer Best Practices (like this initiative strives to
provide)
4.) Lack of software vendors realizing the benefits
5.) Lack of software vendors incorporating URL Best Practices as a key
component of their software design
6.) Many developers views of URLs as something internal
7.) And more, but it's late and I'm no longer thinking clearly.
I also think that a certain class of software architects have value certain
attributes would prefer, in a perfect world, that URLs be hidden. But they
are not; the permeate everything about the web. So I am advocating rather
than procede with the way we want things to be we proceed with the way
things are and embrace the power of clean and meaningful URLs; Sites like
Amazon, Google, eBay, Flickr, and YouTube certainly have and I would argue
that is an important part of their success.
I know some people will point to the fact that a lot of users do not
understand URLs and that is a reason to avoid them. Well, if we always
avoided things users didn't understand we'd never introduce anything new. In
the days before Starbucks almost nobody in the USA would believe anyone
would ever pay $5 for a cup of coffee. Starbucks presented that value
proposition and proved everyone wrong. I believe the same is true of clean
and meaningful URLs. If we create a high value proposition and do a good job
of implementing them, people will learn to use URLs and use them wisely.
(Also remember that as more of the people who entered school after the mid
90's enter the workforce, a greater percentage of users will understand URLs
without even having to give it a second thought.)
One place where I think URLs can be incredibly valuable is in helping to fix
key usability problems with AJAX. But that's a subject for a different venue
(as the above probably should have been.)
>> (long off topic debate possible here about the notion of opacity and
privacy)
Yes, I've been studying that in the past day here[2] and in the yahoo groups
[1], thanks to Nick Gall. From what I read, whoever wrote [2] seems to have
the same ideas that I do.
>> REST ... is not related to URL design :)
That is your opinion. :) Roy T. Fielding however does seems to think URL
design is useful[1]. Even one of the articles you provided me argue for
designing the URLs as the first step in creating an REST web service[3].
But I am always open to have my mind changed given a well-supported argument
as, unlike some people, I don't "stay the course" when I learn that the
course is wrong (hopefully you'll grok that little bit of US-centric
satire... ;-)
>> 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.
I agree we need to take this elsewhere. Repeating what I said above, can you
give me any pointers for sending my first post to that list?
In closing, even though I disagreed with you on some topics I respect you
for your position in the W3C and I greatly appreciate the time you've given
me thus far.
-Mike Schinkel
http://www.mikeschinkel.com/blog
http://www.welldesignedurls.org/
--------
[1]
http://tech.groups.yahoo.com/group/rest-discuss/messages/3188?threaded=1&m=e
&var=1&tidx=1
[2] http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK
[3] http://www.xml.com/pub/a/2004/12/01/restful-web.html
-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Karl
Dubost
Sent: Tuesday, October 17, 2006 9:39 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] "Lightweight Data Access Services" and Well
DesignedUrls
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 ***
_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
More information about the microformats-discuss
mailing list