Re: Boeing XRI Use Cases

Mark,

I believe that you do not need a new URI scheme to extract information from
URIs.  HTML would have needed to create HTMLFORMSURI: or somesuch to do
forms in URIs using your example.  I will again bring up URI templates and
the metadata in URI TAG finding.  I believe that a scheme whereby xris are
denoted by http:// + some authority that can do XRI resolution (such as
David Booth's purl.org suggestion) + a specific format for such URIs is
completely within Web arch.  There's no division of the information space
and web browsers can do GETs on the URIs without special software.  I'm
certainly not prepared to lobby the XRI folks any further than this.  If
they do provide URIs using http:// schemes, I cannae ask them more laddie.

Cheers,
Dave

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

>
> On 7/13/08, Booth, David (HP Software - Boston) <dbooth@hp.com> wrote:
> >  Also, I note in section 11.2, that an HXRI is intended to be
> recognizable by starting with "http://xri." (or "https://xri.").  Wouldn't
> this potentially cause a regular (non-HXRI) URI that happens to start with
> that sequence to be erroneously interpreted as an HXRI?
>
> It would AFAICT, counter to advice from the AWWW[1].  This is why none
> of the suggested fixes, alone or together, address my concerns.
>
> If you're trying to extend the Web in a way that requires providing
> license to agents to extract information from URIs - which appears to
> be a key part of the functionality XRIs are trying to provide (see
> 1.1.1 of xri-syntax) - then you need a new URI scheme.
>
> So I think the discussion of URI schemes for XRIs is pretty much a red
> herring.  What we should, IMO, be talking about, is why http URIs and
> hypermedia weren't used to provide the functionality mentioned in
> 1.1.1.
>
> Cheers,
>
>  [1] http://www.w3.org/TR/webarch/#uri-opacity
>
> Mark.
>
>