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] Linked XRD Processing Rules

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, September 18, 2009 11:38 AM
> To: Eran Hammer-Lahav; 'XRI TC'
> Subject: RE: [xri] Linked XRD Processing Rules
> Reply inline to Eran's questions.
> > -----Original Message-----
> > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
> > Sent: Friday, September 18, 2009 9:57 AM
> > To: XRI TC
> > Subject: [xri] Linked XRD Processing Rules
> >
> > The questions we need to answer in order are:
> >
> > - Is there a need for general purpose processing rules to link one
> XRD to
> > other XRDs?
> Yes. Dropping XRI linking altogether prevents any form of XRD
> delegation. I
> belive that Dirk was arguing that such delegation is really only needed
> in
> /.well-known/host-meta XRDs. That may be true, but I'm not sure what
> mechanism he's proposing for doing that there -- isn't that an XRD?

Yes, but the point would be the same as with dropping 'match'. That since we only have one actual use case, it would be better to let host-meta define a 'replace' directive and wait until we have more implementation experience before we design one for XRD. That's the general idea.

> 2) #next (or whatever other name we might want to use for this) is
> "ordered
> XRDs". Scott and I appear to see this the same way: each XRD is atomic,
> and
> is processing independently according to the same rules (including Type
> selection). There is no aggregation or "include" functionality. The
> rule is
> simply that when you reach a #next link, the XRD consumer fetches the
> next
> XRD and confirms that it is valid. If so, it drops the first one and
> processes the second one.

What do you mean by 'drop'? What if there are more elements after the #next directive? What if there are more #next directive?
> This XRD linking model supports the same delegation option as #replace,
> but
> adds the ability for the first XRD to include links that override those
> in
> the #next XRD because they will be processed first.
> As Scott points out, it has no effect on <Type> selection, because the
> XRDs
> are atomic and processed independently.

This makes #next less useful than #replace in my view for the host-meta use case. It means I can only delegate links to another XRD, which is really what #see-also does. According to this XRD atomic theory (which I do not share), when would a client know when to stop following these #next links? When it is looking for links it is easy (when it finds one), but when will it know that there is nothing else useful to know about a resource, other than to follow them all...


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