OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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  

> 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?


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]