XRDS / Yadis
4 views
Skip to first unread message
Eran Hammer-Lahav
Jan 4, 2008, 2:38:05 PM1/4/08
to DataPortability Workgroup
I think the front page of dataportability.org should list XRDS and not
Yadis. XRDS is the format and Yadis is just a small subset of the
protocol on how to obtain an XRDS document.
EHL
Yadis. XRDS is the format and Yadis is just a small subset of the
protocol on how to obtain an XRDS document.
EHL
Terrell Russell
Jan 4, 2008, 2:40:16 PM1/4/08
to datapor...@googlegroups.com
Agreed.
XRDS is the discovery packaging that will make this go down smooth.
Terrell
--
Terrell Russell
Co-Founder, claimID.com
PhD Student, Information Science, UNC-CH
Eran Hammer-Lahav
Jan 5, 2008, 12:06:15 AM1/5/08
to DataPortability Workgroup
It's still up there... ;-)
BTW, expect an XRDS "lite" spec soon. It will use the XRI Resolution
2.0 but reduce complexity with focus on service discovery. It is very
cool, and is both simple and XRI compatiable.
EHL
BTW, expect an XRDS "lite" spec soon. It will use the XRI Resolution
2.0 but reduce complexity with focus on service discovery. It is very
cool, and is both simple and XRI compatiable.
EHL
Danny Ayers
Jan 5, 2008, 7:59:46 AM1/5/08
to datapor...@googlegroups.com
Hi Eran,
On 05/01/2008, Eran Hammer-Lahav <er...@hueniverse.com> wrote:
> BTW, expect an XRDS "lite" spec soon. It will use the XRI Resolution
> 2.0 but reduce complexity with focus on service discovery. It is very
> cool, and is both simple and XRI compatiable.
Quick question - is it Web-compatible? i.e. can it just use HTTP/URIs
for resolution, or is it necessary to register i-names and use an XRI
resolution service rather than/as well as DNS?
Cheers,
Danny.
<http://dannyayers.com/me#> <http://purl.org/stuff/names/iname> "=danny.ayers" .
Chris Messina
Jan 5, 2008, 12:15:14 PM1/5/08
to datapor...@googlegroups.com
AFAIK, it's web-compatible. It just stipulates the format for an XML
document of pointers to external resources.
document of pointers to external resources.
Chris
Sent from my iPhone
Eran Hammer-Lahav
Jan 6, 2008, 9:50:46 PM1/6/08
to DataPortability Workgroup
Short answer, yes. It is an XML file format that can be retreived via
HTTP/URLs. And when not used for XRI resolution, doesn't need to have
anything to do with XRI in it (except for the namespace declaration).
---
XRI Resolution 2.0 defines two things, one is an extremely useful and
flexible XML schema for describing services and rules of how to select
them. The second is all about XRI authority and resolution which is
where most people get lost and lose interest. Both are very smart
technologies, regardless of where you are on the politics of this.
I care little about the politics behind this (but I do enjoy it!).
What we are doing is taking XRDS which is extremely powerful but
complex, and droping features from it in order to make it easier and
more accessible. This will be called XRDS-Simple. For example, it will
drop all the authority and synonym elements. It drops the advance
service selection attributes. It put strict limits on links between
XRD elements. But it keeps much more than what OpenID uses today, and
leave plenty of good stuff that should enable everything we have been
talking about. The stuff we drop is what makes most developer bleed
from the ear when trying to code against.
I think it will be a gateway format into full XRDS for those who will
find it (Simple) limited. You start with XRDS-Simple which helps you
understand the technology. Then if you need more advance features or
less restrictions, you can look at full XRDS, or as always, you can
build your own flavors or extensions.
Since the #1 objective of XRDS and this group is interoperability,
there is great value in coming up with a standard people can implement
quickly that will enable easy machine-readable documentation of
services. At the same time, we are working closely with the folks
behind XRI to ensure that the simple version will be fully compatiable
with the full version.
XRDS-Simple is just a file format with a few processing rules and
guidelines. We picked a name that will keep us honest and focused to
deliver something that is truely simple and powerful. This is in no
way a dig against XRDS or XRI Resolution. Those are exremely well
thought out technologies that address a pretty large target. But by
doing so, they create a threashold that stands in the way of the
avarage developer from being able to adopt it.
For example, if you wrote your own XRDS parser for OpenID 2.0 based on
the various examples out there, chances are, it will blow up as soon
as someone uses the full power of XRDS with append, select, and match
attributes. Most people can't even handle priorities right.
XRDS-Simple comes out of the needs of OAuth Discovery. Instead of
building our own subset, the XRI guys suggested we work together to
define a subset that will help anyone who needs service discovery
without the full flexibility of XRDS as defined in XRI Resolution 2.0.
A funny thing is, working to decide what goes in and what doesn't, I
had to learn how to use the full schema of XRDS first. As I was doing
so, I got really excited about many of their features. When I made my
first list of what will go in, it was, well, more than 85% of the
original. This is interesting because at some point I started to
question the need for a simple version, as I was coming up with use
cases in my head of how to use this tool. But at the end, when I
started thinking about the people who will implement OAuth Discovery,
I realized 95% of them will never need any of these features, not
matter how cool they are. But if they try to use the 5% who do, their
code will break.
We are no replacing XRDS. I actually think many more people will use
XRDS becuase they will read XRDS-Simple and say, I wish I could also
do that, and then find out they can, if they move to the next level.
But OAuth Discovery will be restricted to XRDS-Simple and doing so
will make it something avarage developers can use.
Expect to see the first public draft of XRDS-Simple in the next couple
of weeks. I plan to release it before SG FC together with OAuth
Discovery draft 2.
As always, feel free to hit me with questions, comments, or requests.
Especially is you use XRDS today and want to make sure some features
are in/out.
EHL
HTTP/URLs. And when not used for XRI resolution, doesn't need to have
anything to do with XRI in it (except for the namespace declaration).
---
XRI Resolution 2.0 defines two things, one is an extremely useful and
flexible XML schema for describing services and rules of how to select
them. The second is all about XRI authority and resolution which is
where most people get lost and lose interest. Both are very smart
technologies, regardless of where you are on the politics of this.
I care little about the politics behind this (but I do enjoy it!).
What we are doing is taking XRDS which is extremely powerful but
complex, and droping features from it in order to make it easier and
more accessible. This will be called XRDS-Simple. For example, it will
drop all the authority and synonym elements. It drops the advance
service selection attributes. It put strict limits on links between
XRD elements. But it keeps much more than what OpenID uses today, and
leave plenty of good stuff that should enable everything we have been
talking about. The stuff we drop is what makes most developer bleed
from the ear when trying to code against.
I think it will be a gateway format into full XRDS for those who will
find it (Simple) limited. You start with XRDS-Simple which helps you
understand the technology. Then if you need more advance features or
less restrictions, you can look at full XRDS, or as always, you can
build your own flavors or extensions.
Since the #1 objective of XRDS and this group is interoperability,
there is great value in coming up with a standard people can implement
quickly that will enable easy machine-readable documentation of
services. At the same time, we are working closely with the folks
behind XRI to ensure that the simple version will be fully compatiable
with the full version.
XRDS-Simple is just a file format with a few processing rules and
guidelines. We picked a name that will keep us honest and focused to
deliver something that is truely simple and powerful. This is in no
way a dig against XRDS or XRI Resolution. Those are exremely well
thought out technologies that address a pretty large target. But by
doing so, they create a threashold that stands in the way of the
avarage developer from being able to adopt it.
For example, if you wrote your own XRDS parser for OpenID 2.0 based on
the various examples out there, chances are, it will blow up as soon
as someone uses the full power of XRDS with append, select, and match
attributes. Most people can't even handle priorities right.
XRDS-Simple comes out of the needs of OAuth Discovery. Instead of
building our own subset, the XRI guys suggested we work together to
define a subset that will help anyone who needs service discovery
without the full flexibility of XRDS as defined in XRI Resolution 2.0.
A funny thing is, working to decide what goes in and what doesn't, I
had to learn how to use the full schema of XRDS first. As I was doing
so, I got really excited about many of their features. When I made my
first list of what will go in, it was, well, more than 85% of the
original. This is interesting because at some point I started to
question the need for a simple version, as I was coming up with use
cases in my head of how to use this tool. But at the end, when I
started thinking about the people who will implement OAuth Discovery,
I realized 95% of them will never need any of these features, not
matter how cool they are. But if they try to use the 5% who do, their
code will break.
We are no replacing XRDS. I actually think many more people will use
XRDS becuase they will read XRDS-Simple and say, I wish I could also
do that, and then find out they can, if they move to the next level.
But OAuth Discovery will be restricted to XRDS-Simple and doing so
will make it something avarage developers can use.
Expect to see the first public draft of XRDS-Simple in the next couple
of weeks. I plan to release it before SG FC together with OAuth
Discovery draft 2.
As always, feel free to hit me with questions, comments, or requests.
Especially is you use XRDS today and want to make sure some features
are in/out.
EHL
Chris Messina
Jan 8, 2008, 3:23:50 AM1/8/08
to datapor...@googlegroups.com
+1
I'm very excited about this Eran.
Chris
--
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412.225.1051
IM: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
Reply all
Reply to author
Forward
0 new messages