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-
[EMAIL PROTECTED]
* 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 [EMAIL PROTECTED] 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
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
