[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: #next: alternate to #replace
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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]