Re: <id> and <link> are broken! (was RE: base and atom:id)

[Dare Obasanjo <kpako@xxxxxxxxx>]

Your entire post is yet another argument that shows
how the fundamental concept of URIs is broken. We had
URLs and URNs but the powers that be decided for
whatever reasons to conflate the two which has been
causing confusion ever since. 

The fact is that an entry needs both a URN (a globally
unique name) and a URL (a way to fetch it's HTML
representation from the Web). Unfortunately, the
IETF/W3C has replaced URLs and URNs with  URIs (a
globally unique name that maybe also has a network
retrievable representation) which simply do not do the
same thing and lead to lots of confusion. 

If anything points to the fact that "web architecture"
is an oxymoron it's the entire URI mess. 

I personally do not see anything wrong with what ATOM
has in <link> & <id> and it is clear what both
elements do. Unfortunately, they conflict with how
certain ex post facto Web architecture design
documents claim is how the Web works. 

--- Danny Ayers <danny666@xxxxxxxxxxx> wrote:
> 
> Let me try putting this point a slightly different
> way (with a more dramatic
> subject). Though it's a valiant effort to solve a
> problem, I don't think
> using one URI to identify an entry and another URI
> to identify a
> representation of that entry works. I think we
> should be looking at a single
> URI for the entry, with dereferencing treated as
> most other http-oriented
> URIs. The retrieved representation should be that of
> the URI in question,
> rather than having one URI act as a proxy for
> another.
> 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #95
My dungeon will have its own qualified medical staff complete with bodyguards. That way if a prisoner becomes sick and his cellmate tells the guard it's an emergency, the guard will fetch a trauma team instead of opening up the cell for a look.

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools