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


What I really had in mind is that discovery would return a list of
XRDs, and there would be a specific concrete answers to these two
types of questions by processing the list:

node = discover(resource, rel type)


Actually, no I can't give the example, because as someone who has
interacted with XRD discovery extensively as an OpenID developer, I
suspect that every existing use case is for either:

node = discover(resource, rel type)
list of Types = discoverType(resource)

However, I realize now that this is undesirable because it requires
pre-fetching all XRDs to answer the first type of question.

Unfortunately Brian Eaton lost a battle early on in this process to
avoid writing a discovery spec that gives meaning to the operation

xrd = discover(resource)

I think that is the source of all complication :) XRDs are treated as
first-class objects, when efficiency and simplicity considerations
indicate that they should be treated as partial representations of a
discovery process, with this spec only defining how to answer each of
the types of question above.

How come we didn't concentrate on this crucial issue early on? At this
point, I think we should stick with #replace. In additional to the
complexity, it has profound consequences from the perspective of
efficiency also.


On Thu, Sep 17, 2009 at 11:01 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> 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)
>



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