[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XML for service endpoint selection output (was RE: [xri] Proposal for _xrd_r parameter and return format)
Wil, I want to avoid bloat every bit as bad as you do. But the more we look this issue, the more it becomes clear to me that not addressing it is going to leave a big hole in the spec -- and worse, one that will directly hurt adoption. Here's why: I think we all agree that HTTP proxy resolvers are going to be the easiest way for many applications to integrate XRIs. They not only offload XRI resolution, but they make it almost trivial to add support for XRIs to local applications, because it turns XRI resolution into a web service (an extremely simple one, because it's just an HTTP GET that returns an XML document). As of ED 06, XRI proxy resolution supports two options: 1) Return a full XRDS document. 2) Return a 3xx redirect to a single URI. The second option is not intended for programmatic access to a proxy resolver, i.e., it's not really a web service, but a method of providing backwards compatability of HXRIs with existing browsers. That's why it doesn't provide a "clean" way of returning an error. So the only means of programmatic access is option 1 -- receiving the full XRDS document, which also provides a clean way of returning an error. However if we stop there, it means XRI proxy resolvers would be handicapped in that even though they MUST contain the code that performs the second phase of service endpoint selection logic in order to produce 3xx redirects, they don't offer applications any way to gain programmatic access to the output of service endpoint selection -- or any clean option of how to receive an error from the service endpoint selection phase. This would be ESPECIALLY dumb because for lightweight applications that want to make programmatic use of XRIs, getting just the service endpoint selection output is the MOST desirable option because that way they don't need to build any service endpoint selection code at all. All the application developer needs to do is: 1) Know the Type value or Path value necessary to select the desired service endpoint he/she wants returned (because that way they can construct the XRI necessary to make the resolution request.) 2) Know the URI of an XRI proxy resolver to make the request. The HTTP proxy resolver as a web service will handle all the rest and return a nice compact little chunk of XML to the application. And in order to support this functionality, all we as spec writers have to do is define: 1) One input parameter that controls the return value. 2) The XML document format for the output of service endpoint selection. In other words, we are 95% of the way there to arguably the MOST useful feature of XRI proxy resolution. So if we can just agree on the simplest and fastest way to do it, we're done. See my next message for a revised proposal based on Les's idea. =Drummond -----Original Message----- From: Tan, William [mailto:William.Tan@neustar.biz] Sent: Saturday, February 25, 2006 4:20 AM To: Drummond Reed; Chasen, Les; xri@lists.oasis-open.org Subject: RE: [xri] Proposal for _xrd_r parameter and return format Having cooked on it for a while, I feel that we don't necessarily have to work this into the specs at this time. IMO, this will add complexity to the resolution spec without adding a lot of value. And I would also point to Victor's suggested reading on how partial implementation helped the web, as fragmented as it is today (http://www.shirky.com/writings/evolve.html) Don't get me wrong, I like the idea a lot, but to be practical, I think we could use a little bloat control and at least defer it to a later revision or a separate document. Just my 2c. =wil (http://xri.net/=wil) > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Saturday, February 25, 2006 4:01 PM > To: Chasen, Les; xri@lists.oasis-open.org > Subject: RE: [xri] Proposal for _xrd_r parameter and return format > > Returning a "mini" or "stripped down" XRDS is certainly an option. If we > went that direction, though, returning just an XRD document might be > preferable. That way we still get the advantage of nothing needing to > change > in the schema, and CanonicalID staying where it is, but the client > receiving > just the final XRD and just the selected service endpoint. > > URIs would still be "fully exploded" per my earlier message. > > Example: > > <XRD xlmns="xri://$xrd*($v*2.0)"> > <CanonicalID>xri://=!A1B2.C3D4</CanonicalID> > <Service > > <ProviderID>xri://!!1000!1234.5678</ProviderID> > <Type select="true">xri://+contact*($v*1.0)</Type> > <Path match="null" /> > <URI > priority="10">http://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> > <URI > priority="15">http://alt.example.com/contact/=!A1B2.C3D4?id=xri://@foo</ UR > I> > > <URI>https://example.com/contact/=!A1B2.C3D4?id=xri://@foo</URI> > </Service> > </XRD> > > What does everyone think? > > =Drummond >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]