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] Example local resolver API and corresponding proxy resolver output.


Les,

1) I agree that it might make sense to return the entire XRD (with the
addition of the new URI elements as describe below) but with only the
*matched* Service elements. This is because Service selection has already
happened, so you are saving the consuming application the job of needing to
select them again. However there may be more than one, and this lets the
consuming application have the option of using the others.

Steve, what do you think of this, i.e., sepResolve returning "all of XRD
less non-matching SEPs"?

2) There's a strong case for calling the URI element by the same name at
both the XRD level and the Service level. Besides the fact that it has the
same contents (a URI), there are other uses for a URI element at the XRD
level. For example, a long time back (early in CD01 days) we discussed
returning a URI at the XRD level as one of the items of metadata an XRD
author could assert about a Resource. It would be the equivalent of saying,
"the resource represented by the query XRI is at this URI".

Since we would define no other semantics or construction rules for a URI at
the XRD level, it would mean that every URI at the XRD level is simply being
asserted as "a URI for the target resource".

This fits very nicely, then, with the resolver doing the work of
"constructing" the URI elements for the XRD level from the selected SEP and
returning them in the sepResolve XRD. Following is an example of the XRD
that would be returned as a result of doing a sepResolve on
"xri://=Drummond/(+contact)":

<XRD xmlns="xri://$xrd*($v*2.0)">
	<Query>*Drummond</Query>
	<Status code="100" />
	<URI> http://xri.iservices.biz/
(+contact)*($v*1.0)/(=!1234.5678.A1B2.C3D4)?xri=xri://=Drummond</URI>
	<CanonicalID>=!1234.5678.A1B2.C3D4</CanonicalID>
	<LocalID>!1234.5678.A1B2.C3D4</LocalID>
	<Service>
		<Type select="true">xri://+contact*($v*1.0)</Type>
		<Type match="null" />
		<Path select="true">(+contact)</Path>
		<Path match="null" />
		<URI append="qxri" >http://xri.iservices.biz/
(+contact)*($v*1.0)/(=!1234.5678.A1B2.C3D4)?xri=</URI>
	</Service>
</XRD>

And the rule would be that any "constructed" URI added to the XRD as part of
service endpoint selection would be placed above any URI element that was
put there directly by the XRD author (not shown above.)

=Drummond 

-----Original Message-----
From: Chasen, Les [mailto:les.chasen@neustar.biz] 
Sent: Monday, February 27, 2006 9:08 PM
To: Steven Churchill; xri@lists.oasis-open.org
Cc: Andy Dale
Subject: RE: [xri] Example local resolver API and corresponding proxy
resolver output.

I like this.  Just a couple of questions.

Re sepResolve() Given that the service block is being returned in XML
why not return the entire XRD block.  This would be instead of multiple
OUTs.

Can we call the URIs in the XRD something like ConstructedUri?  There is
precedence for the same element names being used in different sections
of the XRDS, i.e. providerId.  However, I think that using a different
name makes the difference self explanatory.


 
I-Name:  =les.chasen 
 

-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Monday, February 27, 2006 2:20 AM
To: xri@lists.oasis-open.org
Cc: 'Andy Dale'
Subject: [xri] Example local resolver API and corresponding proxy
resolver output.


Hi all,

Discussions with Drummond earlier today led to the following
proposal. 

The first section describes an example API for the local 
Resolver. The second section shows the proxy resolver's
corresponding outputs based on the value of its argument
_xrd_r which takes on one of three values:
	
xrds    Perform authority resolution only and return the 
        XRDS document.

uri     Perform authority resolution and service endpoint 
        selection, and return the highest priority URI.

sep     Perform authority resolution and service endpoint 
        selection, and return the full set of SEP output 
        information.

___________________________________

Example API for Local Resolver:

[N.B.: Note that the method names correspond to the values of the 
_xrd_r argument used by the proxy resolver.]

[N.B.: I will formalize the documentation after the group has
has had a chance to respond. Currently it's just a list of notes.]

1. int xrdsResolve(
        in string qXRI, in string mediaType, in boolean noFollowRefs, 
        out string XRDS, out string errorContext);

    Notes: 
    -   Performs authority resolution only and outputs the XRDS.
    -   Only the first segment of qXRI is processed.
    -   A null value for mediaType defaults to application/xrds+xml.
    -   All _xrd_ arguments on qXRI are ignored by this operation.
    -   Returns the error code. If error, then the errorContext 
        output argument may contain additional error information. 
        The XRDS will contain an XRD with the same code and 
        optional context information.


2. int uriResolve(
        in string qXRI, in string type, in string mediaType, 
        in boolean noFollowRefs, out string URI,  
        out string errorContext);

    Notes: 
    -	  Performs both authority resolution and service selection,
        and outputs the highest priority URI after URI construction.
    -   The first segment of the given qXRI is used for authority
        resolution phase. The remainder of the qXRI is used as the 
        "path" argument for service selection.
    -   All _xrd_ arguments on qXRI are ignored by this operation.
    -   Returns the error code. If error, then the errorContext 
        output argument may contain additional error information. 

3. int sepResolve(
        in string qXRI, in string type, in string mediaType, 
        in boolean noFollowRefs, out string[] uriArray, 
        out string[] canonicalIDArray, out string serviceXML
        out string errorContext);

    Notes: 
    -	  Performs both authority resolution and service selection,
        and, for the selected service, outputs (1) the (post 
        URI construction) list of URIs in order of priority, (2) 
        the canonicalID list in order of priority, and (3) the
        XML <xrd:Service> service element. 
    -   The first segment of the given qXRI is used for authority
        resolution phase. The remainder of the qXRI is used as the 
        "path" argument for service selection.
    -   All _xrd_ arguments on qXRI are ignored by this operation.
    -   Returns the error code. If error, then the errorContext 
        output argument may contain additional error information. 


___________________________________

Proxy Resolver Output 

This section shows the proxy resolver's output for the three
values of _xrd_r.

1. _xrd_r = "xrds"

    << The output is shown in section 3.2 of the spec. >>

2. _xrd_r = "uri"

    << The output is the highest priority URI subsequent to 
       URI construction. If an error occurs, then the output
       is *TBD* >>

3.  _xrd_r = "sep"

    <xrd:XRD>
        <Status code="100"> 
            [[Would include optional context, if error.]] 
        </Status>

        <URI>http://resolve.example.com/appendedpath?arg=foo</URI>
        <URI>http://resolve2.example.com/appendedpath?arg=foo</URI>

        <CanonicalID>xri://@!1000!1234</CanonicalID>

        <Service>
            <ProviderID>xri://!!1000!1234.5678</ProviderID>
            <Type>xri://$res*auth*($v*2.0)</Type>
            <MediaType>application/xrds+xml</MediaType>
            <URI priority="10">http://resolve.example.com</URI>
            <URI priority="15">http://resolve2.example.com</URI>
            <URI>https://resolve.example.com</URI>
            <OtherMetadata>foo</OtherMetadata>
        </Service>
    </xrd:XRD>


    Notes about the above XML:
    -   URIs are post URI construction and are in order of priority.
    -   CanonicalIDs are in order of priority.
    -   <URI> and <CanonicalID> have no attributes in this context.
    -   The Service element has not been altered by URI construction
        or anything else.
    -   URI is now child of XRD as well as Service :-)


Please provide your feedback ASAP.

Thx,
~ 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_workgroups.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 





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