Karl: 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. >> 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. Since you commented, did you read this first? http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx Do you see recommendations there that you think will cause problems? (Be aware that it's been 16 months since I wrote that and am really ready to revise it.) What I do want to do is shine a light on the cons of various choices for web site developers as well as platform developers (Microsoft is one in need of hearing this message.) 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!) 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? >> As an example Link Ranking Systems have increased spam on the Web and nofollow didn't solve it at all. 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; I'm not trying to create a new "layer" on the web or any new "standards", only "patterns". And nothing like Link Ranking Systems or nofollow. For example: * Once published, don't move the content to another URL * But if you move it, always leave a 301 or 302 redirect when you move a URL * Don't change the meaning of content at a published URL (with caveats, to be later discussed) * Ideally don't use extensions for (X)HTML content. * If you must use an extension for (X)HTML content, use either .HTM or .HTML * 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.) * When you peel off a subdirectory from a URL it should return a valid and appropriate .HTML page * Avoid using "magic numbers" in URLs whenever possible (i.e. use www.mysite.com/cars/ not www.mysite.com/5/) * 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/) * Organize major site divisions by subdomain (I need to put a lot more thought into this one about when and when not to) * Sitemaps and Website URL structures should have a very tight coorelation. * For new websites and website redesign, design your URL structure as one of the first steps. * Plus a *LOT* more... Also, please let's not debate these specific examples HERE (unless they are of the *type* that you caution me about); that's what the blog, list, and wiki are for, and besides I'm writing these on the fly and have not fully fleshed them out yet. I don't want to impose too much more on this list. 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.). However to date there's been no set best practices so the platform developers are like Alfred E. Newman and they say "What, me worry?" ;-) I want to give them something that says "What you are doing when you are not considering your URL structure is creating all kind of problems for all kinds of people and here is why you need to think about your URL design and not consider the URLs your apps create to be just your own private Idaho." I also want to give Windows-centric hosting companies more reasons empower users to clean up their apps URLs. And more. (I hope you undersood my two potentially American-centric puns above. :) This is much more about shining a light into a problem area / area of opportunity than it is specifying some new set of standards. Think of it as similar to Jesse Jame Garrett and his declaration of AJAX (though I could only wish to be that influencial.) Jesse didn't defined any new standard with AJAX, he just applied a name to an existing set of technologies and recommend a set of patterns for how they can be used. So like Jesse, I'm more proposing *PATTERNS*and not *STANDARDS*. Make sense? >> 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? >> 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? >> 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/> How to Build an API * How to Design a Good API and Why it Matters <http://lcsd05.cs.tamu.edu/slides/keynote.pdf> * How to design Good APIs and Why they Matter <http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=325815 8706> * How To Provide A Web API <http://www.sourcelabs.com/blogs/ajb/2006/08/how_to_provide_a_web_api.html> * How to Add an API to your Web Service <http://particletree.com/features/how-to-add-an-api-to-your-web-service/> * Simple API Design <http://loudcarrot.com/Blogs/dave/archive/2004/09/26/552.aspx> * How To Design a (module) API <http://openide.netbeans.org/tutorial/api-design.html%20> I am going to print and read your articles just in case I missed some things while scanning them over. 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. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ P.S. I've also rethought the name "Casual Web Services" and think that is not the best. I'm now thinking "Lightweight Data Access Services." (I changed the subject to recognize that.) Actually, I have an even more creative meme for it, but I'm not ready to reveal that yet. ;) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karl Dubost Sent: Tuesday, October 17, 2006 1:27 AM To: Microformats Discuss Subject: Re: [uf-discuss] "Casual Web Services" and Well Designed Urls Le 14 oct. 2006 à 18:02, Mike Schinkel a écrit : > I recently started working on a project I'm calling "Well Designed > Urls" > (http:///www.welldesignedurls.org/) that has been a pet issue of mine > for a long time. See my Aug 2005 blog post: > > http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx > There are interesting things in your post BUT be careful of Well Known Location issues. Trying to standardize URLs would be very bad by limiting the choices of users. In these cases, there is a balance between what do we improve and what are the problems we create in the ecosystem. As an example Link Ranking Systems have increased spam on the Web and nofollow didn't solve it at all. 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.) Do not confuse Web Architecture with URLs. That's the part which is not understood from REST Web architecture style. I encourage your to read this excellent series of posts by Joe Gregorio http://www.oreillynet.com/tags.csp?tag=rest -- 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@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss