RE: [xri] Delegation Terminology / Linked XRD

[Eran Hammer-Lahav <eran@hueniverse.com>]

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Friday, July 03, 2009 3:04 PM
> To: XRI TC
> Subject: Re: [xri] Delegation Terminology / Linked XRD
> 
> 
> On Jul 3, 2009, at 2:19 PM, Eran Hammer-Lahav wrote:
> 
> > I think there is a lot of confusion when it comes to delegation. XRD
> > does not delegate anything. It simply describes resource attributes
> > which for some application may mean delegation. But it is important
> > to note that XRD only links to other resources.
> 
> yes, we decided on the call yesterday after you dropped off that the
> best way to describe this is simply as "linked XRDs".  Delegation is
> certain the wrong word for it.
> 
> 
> > A link inside an XRD is semantically equivalent to a link header or
> > element associated with the same resource. Applications may want to
> > limit how such links are consumed for performance and simplicity but
> > it does not change the semantic meaning of all these links.
> 
> Right, which is why you identify a linked XRD simply as a linked
> resource with a "describedby" rel value, and "application/xrd+xml"
> media type.  If <Link> really is going to share the same semantics as
> the HTTP Link header et al, then XRDs need to be identified in the
> same way.
> 
> 
> > Also, XRD does not link to anything - it only describes link. It is
> > the resource that links to other resources. XRD really can't do
> > anything other than describe. All other verbs belong to the Subject
> > (according to the XRD authority).
> 
> I think that's just semantics.  But yes, you're right.  Not sure what
> impact that has on the current linked XRD proposal though.
> 
> 
> > I need to catch up on the Linked XRD proposal but it seems like the
> > idea is to explicitly say that when one XRD describes a link to
> > another XRD with relation type describedby, that clients are
> > required/recommended to go and fetch that other XRD as well.
> 
> I go back and forth on whether consuming applications are instructed
> that they SHOULD or MUST fetch the linked XRD.
> 
> 
> > It might also suggest that there is an order of precedence between
> > the links found in the first XRD to those found in the second. Do I
> > have this right?
> 
> Well there is a precedence.  Even though a XRD-linked XRD shares the
> semantics as one linked from an HTTP header, we can't ignore the fact
> that <Link> elements do in fact have a priority.  I remember that LRDD
> specifically stated that determining which one of multiple describedby
> links should be used was application specific.  And that seems to make
> sense because there is no good deterministic way to order them.  We
> can order <Link> elements though, so it makes sense to respect their
> order.

I agree that Link priority must take precedence but that's the easy case. What happens when all priorities are equal.

> > I don't think we can say much more (if any) than that if an XRD
> > describes a link with relation type 'describedby' and media type
> > 'application/xrd+xml', that information found there should be
> > treated as a logical OR with the current XRD.
> 
> a logical OR?  why not an AND?  Can two XRDs not be equally valid (and
> perhaps even with the same weight) for a resource?

OR as in links from both documents are combined. AND means only links appearing in both XRDs are included. 

> -will
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php