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: 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]