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

Cool. Wil, Kermit, please do weigh in. I also cc’d Markus and Victor (only I realized I hit the wrong key and accidentally cc’d Vince Caluori (Cordance CEO), who is probably reading this and wondering what the h*ll he’s supposed to say about this ;-)


I agree, let’s try to close tomorrow. I really want to get out ED07 by Monday night, and there’s a ton of work to do even *without* any other changes.




From: John Bradley [mailto:jbradley@mac.com]
Sent: Thursday, October 25, 2007 11:35 PM
To: Drummond Reed
Cc: 'Chasen, Les'; xri@lists.oasis-open.org; ksnelson@subjectivity.com; 'Tan, William'; 'Vince Caluori'; 'Markus Sabadello'
Subject: Re: [xri] Backtracking




Yes I see that authority resolution is a special default case of the SEP selection process where you have 1 or more more sub segments to process.


My tendency is to code that into the authority resolution recursion function rather than invoking the general SEP selection for each subsegment.


I envision the code as a recursive function that processes sub segments until it reaches the last sub segment or hits a ref/redirect.


At a ref or redirect  you have one or more refs to process.  You iterate through the list by again recursing to the same function with the new parameters.


Once you have consumed all of the sub segments you fallow the ref in the last XRD if there is one.


If the XRD cant be returned you raise an exception and unwind back to your list of refs you are iterating through.


Only then do you invoke the general SEP selection process with the input parameter.


If this fails to find the SEP then there are two choices 1 return SEP not found, or 2 rase an exception and unwind back to your list of refs you are iterating through.


The SEP selection if it encounters a ref invokes the recursive authority resolution with the new input parameters.


This all occurs recursively until all of the possible ref paths have been walked with the service selection parameters, until:

1 a SEP is found, and returned.

2 No Sep is found and all paths have been walked so SEP not found is returned.

3 Heat death of universe if there is a loop.


I have a simple programer way of looking at things.  We can make this work either way.


If you enter into the general SEP selection process for each branch of the tree then there is more overhead and chances for loops.


I would like Wil and Kermits opinions.  

I am good as long as we are all on the same page as to how we handle backtracking and the consequences of that.

I don't want to drag this out, lets try to close this tomorrow.




On 25-Oct-07, at 10:50 PM, Drummond Reed wrote:



In thinking about this, I’m not sure backtracking needs make for “unclean code”. It seems to me that, as the ED07 flowcharts reflect, SEP selection is just as necessary during the authority resolution stage as after it, and thus implementations need to maintain their state in the XRDS “tree” no matter whether they are following Refs at the XRD level or the Service level. (The same thing applies to Redirects but Refs are more complex so in this message we’ll just discuss Refs).


For example, say you want to resolve an XRI for an OpenID SEP, and by following Refs during both authority resolution and SEP selection, you ended out with the following XRDS tree:


XRDS ref=”@a*b*c”

            XRD for *a

            XRD for *b

            XRDS ref=”@x*y”

                        XRD for *x

                        XRD for *y

                        XRDS ref=”@d*e*f”

                                    XRD for *d

                                    XRD for *e

                                    XRD for *f



            XRD for *c                                 ;end of authority resolution

            XRDS ref=”@m*n”

                        XRD for *m

                        XRD for *n

                        XRDS ref=”@p*q*r”

                                    XRD for *p

                                    XRD for *q

                                    XRD for *r          ;end of SEP selection





It seems to me that to keep our backtracking rules simple and clean, an implementation must keep track that when it hits the first Ref and starts the nested XRDS for @x*y, and again when it hits the next Ref and starts the next nested XRDS for @d*e*f. Then when it finishes authority resolution, it knows where it needs to “back up to” to place the final XRD for *c. Then the same thing starts all over again once authority resolution is complete but the resolver needs to follow the Refs it encounters in the final stage of SEP selection.


From that perspective, doing SEP selection during authority resolution is no different than doing SEP selection after authority resolution is over – the only difference is that in the first stage you have a pre-defined SEP selection parameters, while in the second stage you have input-defined SEP selection parameters.


But otherwise the two traversal paths and requirements are the same. So it would seem simpler and more consistent to keep the traversal/backtracking rules the same. (Anything we can do to keep Redirect and Ref processing simpler and more consistent gets my vote since it’s complicated enough as it is.)


I too would very much like to get the other implementor’s (Victor, Kermit, Markus, Wil, that’s you ;-) view on this ASAP – any change here would be much bigger than any of the rest of the changes to ED06, all of which are pretty minor at this point.




From: John Bradley [mailto:jbradley@mac.com] 
Sent: Thursday, October 25, 2007 6:26 PM
To: Chasen, Les
Cc: xri@lists.oasis-open.org; ksnelson@subjectivity.com; Tan, William
Subject: Re: [xri] Backtracking


My question is more what constitutes a failure when the ref is at the XRD level.

While the original query may be performing SEP selection, is it our intent for the authority resolution step to maintain the state of SEP selection?


The current proposal has the Authority resolution stage tracking what service is being asked for, and failing the Authority resolution of the ref if the service is not found so it can try the next ref.


My only concern is that this makes for unclean code.



PS I am not touching the ref must be followed question I have already done that once today.


On 25-Oct-07, at 6:00 PM, Chasen, Les wrote:

I am not sure when this change came about. REFs should only be followed in the search of a service whether at the xrd level or service level.

Drummond, in one of you last emails you indicate that a ref and a redirect at the xrd level have the same behavior in that it is followed without inspection of the local SEPs. This is fine for redirect but not ref. Ref should only be followed if the service being sought is not found.


----- Original Message -----
From: John Bradley <jbradley@mac.com>
To: OASIS XRI TC <xri@lists.oasis-open.org>
Cc: Kermit Snelson <ksnelson@subjectivity.com>; Tan, William
Sent: Thu Oct 25 20:38:42 2007
Subject: [xri] Backtracking

Reading the spec 11.5 and looking at the flowcharts we now have 
backtracking for refs at the XRD level.

For these XRD level refs we iterate through refs and redirects in 
priority order.

My question is what causes backtracking. As we have not moved to SEP 
selection at his point, is success just returning the XRD?

I see and completely agree on backtracking if the XRD is not returned.

However the spec now indicates that we move to SEP selection once the 
XRD is returned and if the SEP is not found we backtrack to the next 
ref in authority resolution.

Before we added refs to SEPs this perhaps made more sense.

I prefer the notion of doing this with SEP refs:

1. authority resolution and finding the XRD,
2. Service Selection,
3. Iterating through authority resolution and SEP selection for each 
ref in priority order.

If we backtrack from SEP selection into authority resolution I think 
it increases implementation complexity.

So we can leave the current behavior and backtrack if no SEP is 
found, or change it to only backtrack if no XRD is found.

I am happy with the backtracking on the SEP refs I think that makes 

I will contribute a clarification for 11.5 depending on what behavior 
people want.

I particularly would like Kermit and Wil's opinions.

I can live with it ether way as long as its unambiguous.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]