RE: [xri] RE: #next: alternate to #replace

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

Can you give me an example of a linked XRD to show how this will work? Walk me through the steps of finding all the <Type>s and picking a <link>.

EHL

> -----Original Message-----
> From: Breno de Medeiros [mailto:breno@google.com]
> Sent: Thursday, September 17, 2009 10:57 PM
> To: Eran Hammer-Lahav
> Cc: XRI TC
> Subject: Re: [xri] RE: #next: alternate to #replace
> 
> On Thu, Sep 17, 2009 at 10:42 PM, Eran Hammer-Lahav
> <eran@hueniverse.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: Breno de Medeiros [mailto:breno@google.com]
> >> Sent: Thursday, September 17, 2009 9:58 PM
> >> To: Eran Hammer-Lahav
> >> Cc: XRI TC
> >> Subject: Re: [xri] RE: #next: alternate to #replace
> >>
> >> Okay, I see the metaphor that you are describing, but XML parsers
> are
> >> not written as compilers.
> >
> > Obviously. But if you look past the XML structure and just think of
> the data items inside an XRD, it is a linear list. As it is currently
> defined, if you grab each linked XRD, strip its <XRD> envelope and
> <Subject> (after trust validation it has no other meaning here), you
> can just insert the rest into the linking XRD.
> >
> >> My point is that since we have potentially many XRD choices for a
> >> resource (depending on the start point), would it be a deal breaker
> to
> >> have discovery potentially generate multiple independent XRDs prior
> to
> >> final selection procedure? I guess the answer is no, as long as
> after
> >> the selection procedure the result is unambiguous.
> >>
> >> The processing rule for <Link> could make the order of preference
> >> fixed so that one always picks the first XRD that matches a
> desirable
> >> 'rel' type. E.g.: depth-first-search.
> >
> > It could but that is up to the protocol to decide. Consider the
> OpenID discussions about the order of precedence across links from
> HTML, HTTP, and host-meta. You don't just collapse them all into a
> single list. The context of where you find the link to the XRD matters.
> >
> >> For <Link>-independent <Type> discovery, only the root XRD would be
> >> used.
> >
> > My question is, how do you envision this to work with the very basic
> use case of one resource redirecting consumers elsewhere for its XRD?
> We started this with an HTTP 301 but because we can't sign HTTP
> redirections, we moved it into an XRD. If <Type>s don't cross XRD
> document lines, these resources will have no <Type>s.
> 
> I did not mean that they would have no <Type>. I meant that the <Type>
> is indicated in a single XRD.
> 
> 
> >
> > EHL
> >
> >
> 
> 
> 
> --
> --Breno
> 
> +1 (650) 214-1007 desk
> +1 (408) 212-0135 (Grand Central)
> MTV-41-3 : 383-A
> PST (GMT-8) / PDT(GMT-7)