Google Groups Home Help | Sign in
Message from discussion Generally confused...
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
Danny Ayers  
View profile
 More options Mar 27, 7:53 pm
From: Danny Ayers <danny.ay...@gmail.com>
Date: Thu, 27 Mar 2008 16:53:43 -0700 (PDT)
Local: Thurs, Mar 27 2008 7:53 pm
Subject: Generally confused...
Hi folks,

I'm finding the spec somewhat disorientating. This may be in part
because I'm coming to XRDS-Simple from a background of regular Web
stuff, and have yet to come across any compelling reason to use XRI
instead of the usual Web standards. I must also admit my starting
point is wondering why XRDS-Simple is needed when as far as I can see
the same facilities could be offered just as easily using RDF+HTTP
without the need for a new spec. But I do want to be able to
interoperate with OpenID and related systems, and no doubt there is
something here I'm missing, so given that...not really sure where to
start...how about the definitions:

[[
Resource:
    A URI-addressable network document or service.
Endpoint:
    An absolute URI at which a Resource is available on the network.
]]

Why is resource being defined beyond the definition of URIs (rfc3986)?
There have been issues elsewhere with the fact that URIs can have a
fragment part (after the #) which HTTP servers don't care about, is
that it? Wouldn't a different name than "resource" been less
confusing?

With "addressable" and "available" comes the implication of an
underlying protocol (URIs alone are just identifiers) - are we talking
HTTP and/or other things? If HTTP, then why is "endpoint" needed - how
does this differ from the URI of the resource?

Nor do I understand the need for HEAD & GET *protocols*. Seems to me
there's tight coupling between client and server here. Might it not be
better to focus on how a conforming agent should behave for particular
kinds of messages, rather than bending HTTP at the method level?

If the client is providing enough information for the server to
understand and be able to facilitate the request, shouldn't the server
be able to provide an appropriate response code? (say 200 Ok/406 Not
acceptable). The approach in the spec seems to undermine the
uniformity of HTTP.

Mark Baker's diagram seems appropriate:
http://www.markbaker.ca/blog/2004/10/29/protocol-independence/

If the aim is for something that isn't regular HTTP then fair enough,
though in that case I would be curious to know why start with HTTP
rather than a custom protocol in the first place.

Incidentally, if anyone knows of any work done on mapping between XRDS
and RDF, I'd like to hear - the old interop thing :-)

Cheers,
Danny.


    Reply    Reply to author    Forward  
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2008 Google