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



+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]