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




Inline.

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

Okay, that helps. So delegation (at least 'replace' delegation) would be
defined in the host-meta spec and we would wait on it in XRD.

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

The "atomic" approach is that each XRD is standalone. So an XRD consumer
handles them one by one. How it navigates them depends on what the XRD
consumer is trying to accomplish. If it is looking for a particular rel, it
processes links in the first XRD until it: a) finds the rel, or b)
encounters a #next. If (b), it loads the next XRD and iterates again. It
continues until it either finds the rel or runs out of XRDs.

See below for the challenge when it comes to properties.

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

Yes, you're right, if the XRD consumer is looking for all the properties of
the resource, it would need to process all the properties in the first XRD,
then if it sees a #next, it would load and process the properties of the
second one and iterate again. So essentially you'd have to treat it like an
#include.

Ugh. That means if we don't want to tackle the property aggregation aspect
of distributed descriptors, then it's down to either #replace or no linked
XRDs at all.

My gut is that if we punt on property aggregation, we should still to define
#replace in XRD 1.0 just so we have the simplest form of delegation.

I will continue to stew on it.

=Drummond 



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