On 26-Oct-07, at 9:46 AM, Victor Grey wrote: John Bradley wrote: 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.
Yes - I've always thought of it that way too.
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.
Yes if by "only then" you mean only when you have finished authority resolution successfully. If authority resolution fails, you don't have a final XRD to do SEP selection on.
Yes, and in that case you backtrack to your list of refs and try the next one in priority order. 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.
That's where you lost me.
Authority resolution and SEP selection must be two distinct phases, it seems to me. During authority resolution, you are either following SEPs of type $res*auth, or REFs or REDIRECTs. If I understand ED 06 correctly, any particular XRD can contain either $res*auth SEPs, or REFs or REDIRECTs, but not mix and match from those - if there are XRD level REFs, there cannot also be $res*auth SEPs in the same XRD. So if you follow a $res*auth SEP, and you are not able to consume all of the subsegments in the authority resolution process that way, you can back up and try another URI from the same $res*auth SEP, or a URI from a lower priority $res*auth SEP in the same XRD. If none of those result in successfully consuming all of the subsegments in the authority resolution process, you have to error out. Same for following REFs - if following a REF does not lead to successful authority resolution, you can try another REF in the same XRD. Otherwise you're done.
Once you have successfully finished the authority resolution process and obtained a final XRD, you can start SEP selection. Here's where it gets really confusing I think. If there are no matching SEPs, but there are XRD level REFs, you can follow the REFs looking for your service. But following a REF involves starting -another- authority resolution chain. But this is separate and distinct from the original authority resolution chain that had to finish before you could start SEP selection.
Have I got that right?
=vg
This is the tricky bit. I am informed that the current spec sec 11.5 intends that if the final XRD is returned and you do service selection on it, and if that " does not" find the required SEP then you must unwind back to the same point that you would have if the XRD was not returned.
In working it through with Steve it became clear that this is a mixing of SEP selection and Authority resolution from the programing perspective.
This can be programed but will cause a much larger tree to be walked especially if you were to try and select for a non existent SEP. Think DOS.
I think the preferred way for authors to do this is use the SEP refs elusively. That way you can directly point at the target SEP without having to wander through a large tree asking each final XRD if they have what you want.
If failing to return the final XRD was the only thing that caused the XRD level ref to try its next sibling then I think It would discourage bad authoring and make the code simpler.
I see the the larger symmetry of having the refs at the XRD level service selection. I am willing to go along as long as people ace all clear on what we are doing.
|