RE: [xri] Bracketing Refs [Authority Resolution]

["Drummond Reed" <drummond.reed@cordance.net>]

Gabe,

The answer is that this proposal addresses one part of the "XRI redirect
problem". The overall problem is that if "XRI redirects" (which we propose
starting in WD10 to simply call "references") are handled as in CD01, a
client resolver might be asked to resolve "xri://@!a!b!c" and get back an
XRDS document describing "xri:@!x!y". This would be very confusing. However
the reason is that the client resolver is supposed to "start over" with
every "XRI redirect".

In the new model, the client resolver would not "start over", but continue
resolution when it finds it needs to follow a reference. Steve's proposal
solved the problem of how this would be represented in the XRDS document.

Since Steve posted this, the editors who were present on Friday's call
agreed (at the end after everyone else had left) not to introduce a new
element for this, but to simply use nested XRDS documents. We've now figured
out all the flowchart modifications and such, and I'm working as fast as I
can to get it all into Working Draft 10 Editor's Draft 4, which we want to
get up by Tuesday morning.

I think it will make it much easier to understand once you see it in that
context.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Friday, January 13, 2006 1:42 PM
To: Steven Churchill; xri@lists.oasis-open.org
Subject: RE: [xri] Bracketing Refs [Authority Resolution]

Before you respond to my other email, could you spell out exactly what
the motivation for this proposal is? Specifically what gap in CD-01 are
you addressing?

	-Gabe 

> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org] 
> Sent: Thursday, January 12, 2006 11:44 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Bracketing Refs [Authority Resolution]
> 
> 
> 
> This proposes a bracketing scheme for outputting Refs during 
> the authority
> resolution phase. This provides a human and machine readable way to
> negotiate a nested Ref resolution hierarchy.
> 
> <XRDS>
>     
>     <XRD-A /> 
>     <RefRes>
>         <XRD-E />
> 	  <RefRes>
>             <XRD-H />
>     	  </RefRes>
>         <XRD-F />
>         <XRD-G />
>     </RefRes>
>     <XRD-B />    
>     <XRD-C />
>     <RefRes>
>         <XRD-I />
>     </RefRes>
>     <XRD-D />
> 
> </XRDS>
> 
> 
> The <RefRes> element is used to bracket the XRDs necessary to 
> resolve a Ref.
> The <RefRes> element MUST appear between two <XRD> elements. 
> (It would never
> fall at the beginning or end, and two <RefRes> elements would 
> never appear
> together.)
> 
> The final <XRD> in the <RefRes> is that used for the 
> subsegment resolution
> of the <XRD> that follows the <RefRes>. Therefore, in the 
> example above, the
> subsegment resolution XRD chain is:
> 
>     G, B, I, D
> 
> Note that, since the <RefRes> "replaces" the preceding <XRD> from a
> subsegment resolution standpoint, the number of (top-level) 
> XRDs in the
> <XRDS> is always equal to the number of authority subsegments.
> 
> ~ Steve
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
> 

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php