Open Issues regarding XRDS Discovery
Christian Scholz / Tao Takashi (SL)
I think there are still some open issues regarding how the service
catalogue is discovered.
I think we should also call the service catalogue the final aggregated
list of services which
have been discovered from whatever source (e.g. 10 XRDS files).
So as I see it the issue are:
- Should AX still be part of the solution. If so with which priority
and in which context
- Should it be possible to link XRDS files (e.g. from YADIS to a
protected one and maybe even further)
- Will XRDS-Discovery the only way to find services? There was a
discussion between me, Chris Messina and
Danny Ayers on the xrds-simple list if maybe we should also use
already existing autodiscovery methods in links,
via rel=me and so on. Julian weighted in in the skype chat along that route.
- Where do you stop doing discovery? Do you follow endless XRDS links
and other discovery methods or do we
recommend a minium set which MUST be followed and then you CAN follow?
We also had a discussion if things like a flickr API should be in a
service catalogue (or could be) and how they might be discovered.
Julian proposed rules like this on Skype:
MyXRDS -> My XFN-ProfilesPage -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
MyXRDS -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
MyXRDS -> MyFlickrPage -> Flickr APi
MyXRDS -> MyFlickrAPi
Problem with XFN or rel=me is of course that no type is specified on
what to expect on the other end. We can assume some way
of profile maybe but probably not much more.
So what are the solutions to these issues? And how do we find
consensus so that we don't
discuss these things forever? And what did I miss?
-- Christian
--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
Julian Bond
8 May 2008 16:56:46
>- Should AX still be part of the solution. If so with which priority
>and in which context
A big part of the XRDS-Simple spec is about discovery. If we're going to
propose an additional for of discovery, then this really has to come
from the XRDS-Simple team and be ratified by them. We can of course work
with them and suggest it.
>- Should it be possible to link XRDS files (e.g. from YADIS to a
>protected one and maybe even further)
I'm not sure exactly what this would mean. If it's a seeAlso type link
that says I've got another XRDS over there, then it may be up to the
consuming app whether it follows the link or not.
>- Will XRDS-Discovery the only way to find services? There was a
>discussion between me, Chris Messina and
>Danny Ayers on the xrds-simple list if maybe we should also use
>already existing autodiscovery methods in links,
>via rel=me and so on. Julian weighted in in the skype chat along that route.
Lots of standards already have auto-discovery methods defined and in
common useage. RSS, Atom, FOAF to name three. These are not going to go
away. We can encourage each group to move to or add XRDS-Simple as an
alternate method but for the foreseeable future consuming apps are going
to have to cope with the current methods as well.
>- Where do you stop doing discovery? Do you follow endless XRDS links
>and other discovery methods or do we
>recommend a minium set which MUST be followed and then you CAN follow?
As above. This has to be up to the consuming app and specific use cases.
>We also had a discussion if things like a flickr API should be in a
>service catalogue (or could be) and how they might be discovered.
>Julian proposed rules like this on Skype:
>
>MyXRDS -> My XFN-ProfilesPage -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
>MyXRDS -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
>MyXRDS -> MyFlickrPage -> Flickr APi
>MyXRDS -> MyFlickrAPi
Not so much rules as a non-exhaustive list of examples of possible
discovery routes. Think through each one and you can see how a consuming
app might follow that route.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
This Way Up
Christian Scholz / Tao Takashi (SL)
On Thu, May 8, 2008 at 6:37 PM, Julian Bond <julia...@voidstar.com> wrote:
>
> "Christian Scholz / Tao Takashi (SL)" <tao.t...@googlemail.com> Thu,
> 8 May 2008 16:56:46
>
> >- Should AX still be part of the solution. If so with which priority
> >and in which context
>
> A big part of the XRDS-Simple spec is about discovery. If we're going to
> propose an additional for of discovery, then this really has to come
> from the XRDS-Simple team and be ratified by them. We can of course work
> with them and suggest it.
That's a good idea. We should post something on xrds-simple.
>
>
> >- Should it be possible to link XRDS files (e.g. from YADIS to a
> >protected one and maybe even further)
>
> I'm not sure exactly what this would mean. If it's a seeAlso type link
> that says I've got another XRDS over there, then it may be up to the
> consuming app whether it follows the link or not.
I meant this mostly for the first step from YADIS to a protected one. If this
also contains links to other XRDS files then it probably should be up to the
consumer if it follows that or not (as you said).
> >- Will XRDS-Discovery the only way to find services? There was a
> >discussion between me, Chris Messina and
> >Danny Ayers on the xrds-simple list if maybe we should also use
> >already existing autodiscovery methods in links,
> >via rel=me and so on. Julian weighted in in the skype chat along that route.
>
> Lots of standards already have auto-discovery methods defined and in
> common useage. RSS, Atom, FOAF to name three. These are not going to go
> away. We can encourage each group to move to or add XRDS-Simple as an
> alternate method but for the foreseeable future consuming apps are going
> to have to cope with the current methods as well.
+1 should probably be mentioned in the spec then.
So we might say in the DP-IMPL about discovery that it MUST do the
XRDS stuff and
CAN follow any other discovery mechanism it likes to.
Should we list examples in the DP-REC files for e.g. profiles etc.
("optionally you CAN follow rel=me links found somewhere")?
> >- Where do you stop doing discovery? Do you follow endless XRDS links
> >and other discovery methods or do we
> >recommend a minium set which MUST be followed and then you CAN follow?
>
> As above. This has to be up to the consuming app and specific use cases.
Well, I would say that at least the first link MUST be followed (if it
exists) to come to
an eventually OAuth protected XRDS file.
> >We also had a discussion if things like a flickr API should be in a
> >service catalogue (or could be) and how they might be discovered.
> >Julian proposed rules like this on Skype:
> >
> >MyXRDS -> My XFN-ProfilesPage -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
> >MyXRDS -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
> >MyXRDS -> MyFlickrPage -> Flickr APi
> >MyXRDS -> MyFlickrAPi
>
> Not so much rules as a non-exhaustive list of examples of possible
> discovery routes. Think through each one and you can see how a consuming
> app might follow that route.
The question is if we should put all those rules in the proposed
discovery process.
Of course any app is free to do that anyway. This probably are all CAN
phrases then.
The question is if we should list all those possible examples or just
leave it out and
say that of course an app is free to use any other discovery method
which is out there.
Julian Bond
>> >MyXRDS -> My XFN-ProfilesPage -> MyFlickrPage -> Flickr's XRDS ->
>> >Flickr APi
>> >MyXRDS -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
>> >MyXRDS -> MyFlickrPage -> Flickr APi
>> >MyXRDS -> MyFlickrAPi
>>
>> Not so much rules as a non-exhaustive list of examples of possible
>> discovery routes. Think through each one and you can see how a consuming
>> app might follow that route.
Thinking back to why I posted all that, I was trying to understand if
the user's XRDS should have an entry for Flickr's API. The point being
that the user doesn't really think in those terms. They just want to say
"here are my pictures". So in that first one,
- User enters there home page URL
- Consuming app does xrds-simple discovery to find their XRDS
- The user's XRDS contains a link to the page with all their other
profiles on
- One of those is a Flickr profile page
- Do xrds-simple discovery on the Flickr profile page to find Flickr's
xrds
- Flickr's xrds documents Flickr's API endpoints and the LocalID for
that page
At that point the consuming app has an identified user, it knows their
Flickr ID, it knows where the Flickr API endpoint is today. And each
player is only documenting and publishing the information they're
responsible for.
The second is a simplification that stills makes sense. The user's XRDS
could be a list of profile pages. One of these is their Flickr profile
page. The big list of profile pages would then probably end up in
multiple places so it would be up to the user's app to manage it. eg
XRDS, HTML page or page block, FOAF and possibly others.
In the 4th. Should the user's system know and maintain where Flickr's
API endpoint is? Although perhaps Type=FlickrURI, LocalID=FlickrID is
enough as the consuming app has hardcoded knowledge of Flickr's API.
Which is likely. All it really needs is "Flickr" and a "Flickr member
ID" to be able to use it.
Christian Scholz / Tao Takashi (SL)
On Fri, May 9, 2008 at 10:07 AM, Julian Bond <julia...@voidstar.com> wrote:
>
> "Christian Scholz / Tao Takashi (SL)" <tao.t...@googlemail.com> Thu,
> 8 May 2008 21:51:25
>>> >MyXRDS -> My XFN-ProfilesPage -> MyFlickrPage -> Flickr's XRDS ->
>>> >Flickr APi
>>> >MyXRDS -> MyFlickrPage -> Flickr's XRDS -> Flickr APi
>>> >MyXRDS -> MyFlickrPage -> Flickr APi
>>> >MyXRDS -> MyFlickrAPi
>>>
>>> Not so much rules as a non-exhaustive list of examples of possible
>>> discovery routes. Think through each one and you can see how a consuming
>>> app might follow that route.
>
> Thinking back to why I posted all that, I was trying to understand if
> the user's XRDS should have an entry for Flickr's API. The point being
> that the user doesn't really think in those terms. They just want to say
> "here are my pictures". So in that first one,
> - User enters there home page URL
> - Consuming app does xrds-simple discovery to find their XRDS
> - The user's XRDS contains a link to the page with all their other
> profiles on
> - One of those is a Flickr profile page
> - Do xrds-simple discovery on the Flickr profile page to find Flickr's
> xrds
> - Flickr's xrds documents Flickr's API endpoints and the LocalID for
> that page
The question might be how services end up in the XRDS file. The assumption I can
see from our docs riight now is that vendors will call some update
mechanism to pu their
services in the users XRDS file. In that case flickr could do that if
they support
it. Another scenario would be a thrid party app which maybe crawls all the users
publically available links (rel=me and others) and collects all the services. If
the user links to the flickr page it would then find this service and put the
appropriate URL in that XRDS. Even today this could work already without
flickr changing anything if either the flickr API is used or the RSS photo feed
is listed.
For a more automatic approach it depends on what vendors implement I guess.
> At that point the consuming app has an identified user, it knows their
> Flickr ID, it knows where the Flickr API endpoint is today. And each
> player is only documenting and publishing the information they're
> responsible for.
>
> The second is a simplification that stills makes sense. The user's XRDS
> could be a list of profile pages. One of these is their Flickr profile
> page. The big list of profile pages would then probably end up in
> multiple places so it would be up to the user's app to manage it. eg
> XRDS, HTML page or page block, FOAF and possibly others.
One idea might be: If I list all my other profiles on a service like Pownce
or friendfeed anyway, they can also produce an XRDS file from them eventually
discovering what other services might be available at those URLs I give.
It would be great to have a library to do that of course :)
> In the 4th. Should the user's system know and maintain where Flickr's
> API endpoint is? Although perhaps Type=FlickrURI, LocalID=FlickrID is
> enough as the consuming app has hardcoded knowledge of Flickr's API.
> Which is likely. All it really needs is "Flickr" and a "Flickr member
> ID" to be able to use it.
yep although it still would be great if there would be a more standardized way
of listing images. The Microformats IRC people suggested hAtom with
rel=enclosure
for the images. Problem here is still that you have to parse all hAtom
services as
you don't know which one has the images, the videos or the mp3s.
I am also not sure how batching in such cases is handled as you unlikely have
all photos on one page (could be solved of course by link-tags which
can be parsed,
seems finally to be some use for them ;-)).
But of course it does not hurt to list a flickrAPI endpoint. Even if
it's not an official
standard it might make sense for some applications to know about it and use it.
And another thing they seem to be opposed to was XRDS for disovery. Their
opinion was that you follow XFN links and check out what's on those pages.
My fear is just that this is too slow. If you search for photos you can simply
filter the XRDS for that type. If you only have rel=me links then you'd have to
read all those pages, check if there's a matchign format on them and filter
them that way. This takes time.
Now the question is how we go from here. Like what of all that do we
put in the process?
I personally would be inclined to say: Just use XRDS because an XRDS
file can always be created
by third parties by whatever discovery mechanism is out there.
The other option would be: Make it completely free to the services but
ensure that they
at least implement ONE of a list of discovery options (we might need
to list those individually
for every type of data as they are different, e.g. RSS vs. rel=me, vs.
FOAF vs. ...)
I also wonder if anybody else has an opinion on that :)
(another option is to start coding and just experiment with things)
-- christian
Julian Bond
9 May 2008 12:35:26
> And another thing they seem [Microformats group] to be opposed to was
> XRDS for discovery. Their opinion was that you follow XFN links and
> check out what's on those pages. My fear is just that this is too
> slow. If you search for photos you can simply filter the XRDS for that
> type. If you only have rel=me links then you'd have to read all those
> pages, check if there's a matchign format on them and filter them that
> way. This takes time.
Thinking more and doing some research on this. rel=me links to external
services are almost always on the same page as the home page. The big
list of contacts almost always isn't on the same page. So I feel the
need for a link that says "here's my contacts". I suppose that could be
<a href="contacts.php" rel="contact"> But that's not saying quite the
same thing. contacts.php is NOT one of my contacts. It's the URL where
my contacts can be found. Which keeps bringing me back to Microformats
needing a set of discovery tags. You can't put everything on the home
page. And there is a set of pages that are mostly about one particular
microformat. So we need a link between the two to avoid just spidering
the whole site. That link could be any of (or all of) a marked visible
link, an invisible <link> or an XRDS entry.