RE: [xri] Linked XRD Processing Rules

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

I want to point out that we still have the semantics of 'describedby' which really means include but without any required processing rules. So protocols can simply use that and define clear processing instructions.

I am not sure yet how I am going to solve this for host-meta but I am considering doing just that. However, the subject of any linked XRD in the case of host-meta will still need to be the same.

EHL

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Friday, September 18, 2009 12:52 PM
> To: Eran Hammer-Lahav; 'XRI TC'
> 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