Subject: Notes on draft-hammer-discovery-04

From: John Panzer <[email-masked]>
Date: Wed, 24 Mar 2010 09:25:20 -0700

Some comments and questions about section 3, Discovery Process:

The section lists two use cases, one in which a client is looking for "a
link" and another in which a client is looking for "metadata ... other than
a link to another resource".

(1) It would be good to have an example of the latter.
(2) What if a client simply wants to retrieve all of the available metadata
-- including links -- for a given resource, honoring the host-priority, but
doing a full transitive closure retrieval of everything of interest?  This
is an extremely natural thing to do, especially for a caching client, and
should be possible if the specification is logically consistent.  But
there's no mention of this use case.

I am particularly interested in #2 as I'm about to dive in to
write-or-update code to do this.

(3) The following section leaves me with additional questions:

> If the information being sought is a link: find a link matching the desired criteria by processing the links in order.  If a qualified link is found, the process ends successfully.

Typically one is searching for links with a given rel value, and in the
general case this results in a collection of links. The wording above seems
to be aimed at the (simple) case where you are looking for a link with
cardinality 0 or 1.  But it doesn't address the general case.

If you are looking for a set of links, the spec could either say that all
links with a given rel value MUST be co-located in the same document.  Or,
it could say that clients MUST keep searching all documents (honoring
host-priority) until they exhaust the possible set of documents looking for
rel values.  Are there any other choices?

--
John Panzer / Google
<[email-masked]>[email-masked] /
abstractioneer.org<http://www.abstractioneer.org/>/ @jpanzer

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 25 Mar 2010 18:03:01 -0700

Thanks John.

> -----Original Message-----
> From: John Panzer [mailto:[email-masked]]
> Sent: Wednesday, March 24, 2010 9:25 AM

> The section lists two use cases, one in which a client is looking for "a link" and
> another in which a client is looking for "metadata ... other than a link to
> another resource".
> 

For example, looking for a resource property such as:

<?xml version='1.0' encoding='UTF-8'?>
<XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>

           <Subject>http://example.com/post?id=1</Subject>
           <Property type='http://spec.example.net/blogapi' />
</XRD>

> (2) What if a client simply wants to retrieve all of the available metadata --
> including links -- for a given resource, honoring the host-priority, but doing a
> full transitive closure retrieval of everything of interest?  This is an extremely
> natural thing to do, especially for a caching client, and should be possible if
> the specification is logically consistent.  But there's no mention of this use
> case.

I think this is implied. If you are looking for more than one qualified link, just keep going. The workflow is focused on getting the first qualified link. If that fails, you get the next qualified link. But if you feel this is important to address directly, I can tweak the language to address that.

> > If the information being sought is a link: find a link matching the desired
> > criteria by processing the links in order.
> >  If a qualified link is found, the process ends successfully.
> 
> Typically one is searching for links with a given rel value, and in the general
> case this results in a collection of links. The wording above seems to be aimed
> at the (simple) case where you are looking for a link with cardinality 0 or
> 1.  But it doesn't address the general case.

The link cardinality doesn't matter. You grab the first one you find. If you want all links you just go ahead and continue (instead of returning a link, you add it to a list and continue).

However, rel='lrdd' links are treated differently, where you only use the first link, ignoring all other rel='lrdd' links in the same source. This was done to make client simpler and remove the ability to link to a list of LRDD documents. I am not a client developer so removing this restriction is not going to bother me much. Any thoughts?

> If you are looking for a set of links, the spec could either say that all links with
> a given rel value MUST be co-located in the same document.  Or, it could say
> that clients MUST keep searching all documents (honoring host-priority) until
> they exhaust the possible set of documents looking for rel values.  Are there
> any other choices?

This is what I didn't want to do. I don't want to require full processing of all links. I think most applications will be satisfied using the first qualified link they find.

EHL