[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Special XRI TC unofficial telecon Tue 2/28 4-5PM Pacific
Les has confirmed that he can host a special telecon on the XRI resolution
interface tomorrow (Tuesday) at 4PM PST/7PM EST (Wed. morning for Wil).
The agenda for the call is to:
1) Discuss and if possible close on Steve's proposal (see thread below).
2) Agree on publication/review schedule the rest of this week to get Working
Draft 10 totally out the door.
Date: Tuesday, 28 February 2006 USA (Wed morning Australia)
Time: 4:00PM - 5:00PM PT
TO ACCESS THE AUDIO CONFERENCE:
Dial In Number: 571-434-5750
Conference ID: 5474
Please feel free to post any further thoughts/feedback on Steve's proposal
to the list prior to the call (the shorter the call the better ;-)
=Drummond
-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net]
Sent: Monday, February 27, 2006 5:34 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 really appreciate the thinking Steve has put into this. I like this
proposal for five reasons:
First, it's a unified proposal for all XRI resolution outputs for both local
resolvers (i.e., API-based calls) outputs and proxy resolvers (i.e., XML
"web service"-based calls).
Second, it requires exactly one change to the XRD schema, which is the
addition of the URI element at the XRD level (vs. the Service level where it
already lived.)
Third, Steve has IMHO very elegantly optimized the output of the sepResolve
call so it is of maximum utility both to local applications calling a local
resolver and web applications calling a proxy resolver.
Fourth, the uriResolve call is the lightest weight call of all, and
potentially the most useful to many applications (local or web) that just
want to convert an XRI into an URI and be done with it.
Lastly, the sepResolve call allows a calling applications to receive all
extension metadata that the XRD author may have included in the XRD while
still receiving the benefit of the local or proxy resolver having performed
SEP selection and URI construction.
Because we want to close this so badly, I'm proposing a call tomorrow
(Tuesday) afternoon at 4pm PST/7pm EST (Wed. morning for Wil). Steve and I
can both attend and I believe so can Les (which would be great because he
can host it - Les, pls. confirm w/me if that's so). If Wil, Gabe, Victor,
and anyone else that cares about closing this issue of the XRI resolver API
can attend, we can hopefully come to consensus on this last remaining
technical issue, publish ED 07 on Wednesday, review it on the XRI TC call on
Thursday afternoon, and publish Working Draft 10 Final Edition on Friday.
Halelujah!
=Drummond
-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Sunday, February 26, 2006 11:20 PM
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]