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

[Breno de Medeiros <breno@google.com>]

Sorry, not enough coffee. My last paragraph should actually read:


> 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, #include semantics have 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)
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)