RE: [xri] Clarity around Ref processing behavior.

["Steven Churchill" <steven.churchill@xdi.org>]

Wil, 

It would be a shame to see the original semantics get morphed into the those
you describe below. 

1) These original semantics are currently presented in the spec. It is
difficult to imagine that one could interpret the flowcharts in 8.1.2 and
11.1 to express the semantics you describe. In any case, if you and I can
disagree so much on this, then this points to a flaw in the spec from an
interoperability standpoint--the spec needs to be clear either way.

2) The semantics that you describe were invented after the fact--arising
from implementation considerations--they have nothing to do with the
original use case that motivated Refs. Allow me to explain how Refs were
originally intended to work. 

I will do so by example. 

Consider the XRI authority for @ootao*steven.
http://beta.xri.net/@ootao*steven?_xrd_r=application/xrd%2Bxml;sep=false

As you can see by the XRD, this authority defines no OpenID SEP but contains
a Ref to =steven.churchill in the form of =!C5FB.53B6.6E94.824. 

Therefore, if I resolve the identifier @ootao*steven for it's OpenID
service, I get back the authority for =steven.churchill.

http://beta.xri.net/@ootao*steven?_xrd_t=http://openid.net/signon/1.0&&_xrd_
r=application/xrd+xml;sep=true;

Why does a Ref behave this way? Because that was the original use case: it
allows @ootao*steven to use a service from another authority. In this
example @ootao*steven is using the OpenID service for =steven.churchill.

Now let's say that I decide that I want @ootao*steven to use the XDI service
from a different authority, say @xdi*steven. I should be able to simply
place a Ref to @xdi*steven (and, of course, not define the XDI service for
@ootao*steven.)

Your semantics do not allow this basic use case. Again: your semantics are
about implementation considerations: speed, debugging, etc--not about
satisfying the requirements.

~ Steve

PS: The term "backtracking" is a red herring. All recursion backtracks,
because all recursion uses a stack. What you are trying to say is that you
don't want to traverse a second child.

-----Original Message-----
From: Tan, William 
Sent: Thursday, September 20, 2007 2:35 PM
To: Steven Churchill
Cc: xri@lists.oasis-open.org
Subject: Re: [xri] Clarity around Ref processing behavior.

We have discussed this before -- whether multiple Ref's have round-robin 
semantics or aggregation semantics.

While I agree that aggregation semantics is cool and is in fact more 
intuitive, I have always felt uncomfortable with it from the standpoint 
of predictability.

After discussing this at the TC call today, we led ourselves back to the 
"no back-tracking rule" which has the following advantages:
1. It exposes any error that it encounters early. If we found an error 
but ignored it moving on to the next Ref, the error could stay 
undiscovered for a long time while causing strange resolution behaviors.
2. It enforces a more predictable Ref usage pattern that follows down a 
single Ref chain instead of a Ref tree. This is often easy to understand 
and troubleshoot.
3. Having the constraint above, resolution will probably be faster 
because the resolver wouldn't have to try other Refs.

Drummond also brought up an interesting point that XRD/Ref has a focused 
but limited role in allowing one to aggregate services. Rather, the new 
Service/Ref provides more fine-grained control.

Look for Drummond's minutes for the call and let us know what you think.

=wil

Steven Churchill wrote:
>
> The "processing" flowcharts in sections 8.1.2 and 11.1 both contain a 
> box saying "Resolve Authority Ref to new XRDS document or error". If 
> "Error" is true, then there is a branch to obtain the next Ref.
>
> The original use case for Ref processing held that the "error" 
> occurred either if a Ref could not be followed due to network error or 
> if following the Ref came up empty for the requested service type. 
> That is, in both cases, the code should try following the next Ref. [I 
> will omit for now the explanation as to why this use case is 
> important, but will gladly explain if asked.]
>
> I've heard Wil say at some point that the current OpenXRI 
> implementation only tries the next Ref due to network failure-but 
> doesn't try the next Ref if the "Resolve Authority Ref to new XRDS 
> document or error" comes up empty for the given service type.
>
> Wil, is my statement accurate? If so, I propose that the OpenXRI 
> behavior be changed to (what I consider) match the flowcharts.
>
> ~ Steve
>
> PS: the "note" in the both flowchart refers to section 10. This is 
> incorrect.
>