Re: Boeing XRI Use Cases

Mark,

Part of the issue is the confusion as to whether strings prefixed with xri:
is a new URI scheme or not.  A variety of people and XRI documents have said
that xri: prefixed strings are NOT URIs because such xri: strings are not
valid URI strings, hence the need for the XRI to URI mapping.  My
interpretation, perhaps wrong, is that a new string identifier format was
being proposed that was NOT a URI.  There is quite some documentation to
support this, such as the material that specifies that a URI prefixed by
xri: may be interpreted as an XRI in the presence of an XRI base
declaration(not sure quite the terminology used) and? the absence of a URI
base declaration such as xml:base.  Which means every XML processor needs to
be preceeded by an XRI processor for the correct processing of any xri:
strings.

Cheers,
Dave

On Mon, Jul 14, 2008 at 10:04 PM, Mark Baker <distobj@acm.org> wrote:

>
> Hi John,
>
> I suspect you're asking a lot of questions here to the TAG, rather
> than specifically to myself, so forgive me for just responding to
> those questions that I feel I'm in a position to respond to.
>
> On 7/15/08, John Bradley <john.bradley@wingaa.com> wrote:
> > Hi Mark,
> >
> > If we were to proceed with David's recommendation to remove the xri:
> scheme
> > from the spec and use the HXRI form for web compatibility through a
> proxy,
> > then we would need some way for XRI aware applications to recognize what
> the
> > actual protocol of a http scheme URL is.   We are open to finding the
> > optimal way to achieve this.
> >
> > We had been operating under the impression that the scheme of a URI was
> > designed to do that.
> > This we are told is outdated information.
>
> No, you were correct to use a new URI scheme.
>
> Just because new URI schemes are more often than not a bad idea,
> doesn't mean one should standardize a way to replace URI-scheme
> functionality elsewhere in the syntax of a URI.
>
> IMO, the advice you've been given to avoid new URI schemes should have
> been rephrased to make it clearer where the problem was.  The advice
> should have been to try and solve the problems that XRIs are intended
> to solve using http URIs (without additional license ala HXRIs).
>
> > I ask, are all protocols and transports that are requested to use the
> http
> > scheme going to be subjected to the same level of scrutiny?
>
> Absolutely.  The bar is pretty high over on uri-review, where we
> regularly have to educate folks about the value of reusing existing
> schemes such as http.
>
> > Just for my clarification, is your position that, if XRI can be shown to
> > meet certain standards of utility it should register the xri: scheme?
> This
> > will allow the authority segment of the http scheme to remain opaque.
>
> Yes.
>
> Mark.
> --
> Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
> Coactus; Web-inspired integration strategies  http://www.coactus.com
>
>