[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Delegation Terminology / Linked XRD
> -----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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]