RE: Boeing XRI Use Cases

Marty,

I think XRIs have a major adoption problem.  Their special properties are only useful to the extent that machines can recognize them and invoke their special semantics.  And people are not jumping all over themselves to implement new URI schemes in their software.

On the other hand, HTTP is ubiquitous.  This is why I believe you will have significantly greater success piggybacking the XRI ideas on top of HTTP URIs, rather than inventing an new URI scheme.

I see that the XRI 2.0 spec already defines lossless transformations to and from IRIs (and hence URIs):
http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html#_Converting_XRIs_to_URIs
http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html#_Toc117301857
so presumably an absolute XRI reference and its corresponding absolute URI reference could be considered semantically equivalent.  I notice that such a URI reference always starts with the string "xri:", so presumably that string is how XRI-aware software would recognize that the URI is a URI-encoded XRI, and interpret its meaning as defined in the XRI spec.  Surely there is nothing magic about that particular string: if the XRI spec had instead decided on some other arbitrary URI-conformant string such as "fribblejam:", and written the specs accordingly, XRIs would work just as well.

Suppose the OASIS XRI technical committee (TC) were to decide to make XRIs more web friendly and lower the barrier to their adoption by writing a second "HTTP-XRI" spec that bases XRI's on http URIs roughly as follows.

1. The new HTTP-XRI spec is written to require the string
"http://purl.org/xri/" at the beginning of an HTTP XRI, instead of starting with "xri:".  Aside from this simple syntactic difference, the structure and semantics are defined to be *exactly* the same as for an existing URI-encoded XRI.  (Okay, I will admit that some additional %-escaping might be needed also -- I haven't checked the syntax rules in enough detail to know -- but surely that is a technical detail that could be worked out, and does not significantly affect the point of this example.)

2. The TC registers the http://purl.org/xri/ subspace of purl.org's URI space and sets up a corresponding partial redirect so that when a HTTP XRI such as http://purl.org/xri/@boeing.com/(@example%2Fabc%252Fd%2Fef) is dereferenced in a browser, some useful information is returned, perhaps along the lines of:

        - General marketing info about HTTP-XRIs, what they mean, how great they are and how to adopt them;

        - Specific info about http://purl.org/xri/@boeing.com/(@example%2Fabc%252Fd%2Fef), perhaps by forwarding the request to a boeing.com server; and/or

        - Pointers to HTTP-XRI plug-ins or toolkits, to help bootstrap the adoption of XRI-aware software.

Some observations:

 - HTTP-XRI-aware software would merely look for "http://http-xri.org?xri:" at the beginning of a URI instead of looking for "xri:", and thereafter apply the *exact* same processing as it would for URI-encoded XRIs, since HTTP XRIs would have the *exact* same semantics.

 - Non-HTTP-XRI-aware software would not know about the special semantics of these URIs (just as non-XRI-aware software would not know about the special semantics of XRIs), so it would not be any worse off than for the XRI case.  However, the software *might* still be able to retrieve useful information by dereferencing the URI that it could present to the user, which could not be done in the XRI case.

 - Software that is only *partially* XRI-aware might not have the ability to do XRI resolution -- HTTP resolution is ubiquitous, but XRI resolution clearly is not -- *but* it may still know a little about XRIs and may still be able to make use of some of the information returned by dereferencing the HTTP XRI, which also could not be done for the XRI case.

In other words, for the most part, HTTP-XRIs would have virtually the same benefits as existing XRIs, plus they would have additional advantages:

 - they would be more web friendly (following good web architectural principles of not creating new URI schemes); and

 - being potentially dereferenceable with HTTP, they could have a significantly lower barrier to adoption as compared with existing XRIs.

Of course, as with anything, there is a down side:

 - The URIs would be a little longer.

 - A person looking at an HTTP XRI who is not familiar with XRIs may not immediately realize that it has special XRI semantics.  But being potentially dereferenceable, HTTP XRIs could give them an easy way to find out.

 - Dereferencing by non-XRI-aware software would depend on the stability of purl.org, and there is no absolute guarantee that purl.org will continue to exist and be supported years from now.  On the other hand, there is no guarantee that XRI resolution software will continue to be supported years from now either.  And if I were deciding where to place my bet, I'd say it is *substantially* more likely that purl.org will continue to be supported years from now than that XRI resolution software will continue to be supported, but of course others may think differently.

My question: what would you think of the pros/cons of such an approach?



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Statements made herein represent the views of the author and do not necessarily represent the official views of HP unless explicitly so stated.


> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org]
> On Behalf Of Schleiff, Marty
> Sent: Friday, July 04, 2008 3:10 AM
> To: Ray Denenberg, Library of Congress
> Cc: www-tag@w3.org
> Subject: RE: Boeing XRI Use Cases
>
>
> Hi Ray (& All),
>
> I apologize that this response is so much longer than your question.
>
> ** Examples for Fully Qualified Identifiers: **
>
> At Boeing my employee number (which we call a BEMSID) is 27256. We've
> registered "boeing" in the XRI "@" namespace.
> "@boeing*bemsid*27256" is
> a Boeing minted XRI representing me. We have an inventory management
> system (which we call "CIIM") in which computing device IDs
> are managed.
> We could have a device ID with a value of 27256 (we don't
> currently, but
> the potential exists). "@boeing*ciim*27256" would be a Boeing
> minted XRI
> representing that device. We have an application registry in which
> alpha-numeric identifiers are associated with applications.
> At one point
> we had a registered application called 27256.
> "@boeing*applications*27256" is a Boeing minted XRI representing that
> application. As we now routinely authenticate & authorize breathing
> users, web service applications, and devices to access networked
> resources, we need to differentiate between 27256 the breathing user,
> 27256 the device, and 27256 the application.
>
> ** Examples for Identifier Types in Directories: **
>
> Note that this use case is something we hope to be able to do in the
> future; today we're still forced to use different attribute
> types in our
> directory. The string value "cn=27256,ou=people,o=boeing,c=us" is
> obviously not equal to "CN=27256;   OU=People, o=BOEING; c=US". But if
> those two values are distinguishedName (DN) string
> representations, then
> they are considered equal. Although not yet defined, for purposes of
> this example, let's assume that XRI metadata has been extended so that
> "$dn" represents an identifier type of distinguishedName. Our
> directory
> (after being enhanced to support XRI metadata) could
> recognize that the
> following two XRIs are equivalent:
>
>    $dn*(cn%3D27256,ou%3Dpeople,o%3Dboeing,c%3Dus)
>
>    $dn*(CN%3D27256;%20%20%20OU%3DPeople,%20o%3DBOEING;%20c%3DUS)
>
> Note that URI syntax, and therefore XRI syntax, requires percent
> encoding for spaces, slashes, and certain other characters
> appearing in
> an XRI cross reference(the part between the parentheses), yielding
> complex looking identifiers. However, identifiers expressed within XRI
> cross references are probably most useful to infrastructure
> applications, and would tend to be hidden from end users.
>
> Assuming XRI metadata has been further extended so that "$openid"
> represents an identifier type of OpenID and "$handle" represents an
> identifier type of Handle, then our directory could know the
> appropriate
> matching rules to use for identifiers like the following:
>
>    $openid*(http%3A%2F%2Fmls.signon.com)
>
>    $handle*(123%2F4567)
>
> ** Why suggested alternatives (http:) are inadequate: **
>
> I recognize that mechanisms described in
> http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 could be used by
> minters to manifest characteristics of identifiers and claims about
> identifiers (like matching rules, sorting rules, persistence, one-time
> pseudonym, resolution protocols, presence of check digits). Mentioned
> mechanisms include use of naming conventions (mentioned in section 2.1
> and 2.6), use of the query component (mentioned in section
> 2.5), use of
> response headers (mentioned in section 2.6), and naming authority
> imposed constraints (mentioned in section 2.6). Are there
> others that I
> missed?
>
> I frown on the response headers mechanism. If for some reason
> resolution
> of an http: URI fails (network problems, site down for maintenance, or
> the URL is intended as a simple identifier with no corresponding web
> page) then no response headers are returned. I much prefer identifier
> metadata (not resource metadata) to be inherent in the identifier.
>
> I agree with the TAG finding on The Use of Metadata in URIs (see
> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html). Section 2.1
> states "Web software MUST NOT depend on the correctness of metadata
> inferred from a URI, except when the encoding of such metadata is
> documented by applicable standards and specifications." So to rely on
> metadata inferred by naming conventions, a naming authority's
> use of the
> query component of http: URIs under its control, or a naming authority
> imposed constraint, such conventions and constraints need to be
> documented in standards, specifications, Web and Internet RFCs and
> Recommendations, documentation provided by the URI assignment
> authority,
> or some such place.
>
> When you (or your software) encounters a URI like
> "http://mls.signon.com" how do you (or your software) know
> where to find
> the documented constraints and/or conventions? Can you tell
> that it's an
> OpenID and therefore has certain characteristics and behaviors? How
> would you (or your software) even ask signon.com where they keep their
> documented conventions and constraints. If you (or your software)
> actually succeeded in finding signon.com's documentation, how
> would your
> software make sense of it? Can you (or your software)
> recognize whether
> or not "http://mls.signon.com" is persistent or reassignable? Even if
> the identifier included some metadata (e.g.,
> http://mls.persistent.example.com), would you (or your software)
> recognize it as meaningful metadata?
>
> I think the fourth Conclusion in section 3 of The Use of Metadata in
> URIs does a pretty good job of explaining why naming conventions and
> constraints imposed by naming authorities are not adequate for the
> representation of metadata in URIs: "People and software using URIs
> assigned outside of their own authority should make as few
> inferences as
> possible about a resource based on its URI. The more dependencies a
> piece of software has on particular constraints and
> inferences, the more
> fragile it becomes to change and the lower its generic utility." XRI's
> use of syntactic metadata (not inferred metadata) is useful
> both within
> and beyond the scope of a particular naming authority, which is a
> compelling justification for XRI.
>
> Thanks for your interest,
>
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Information Security - Technical Controls
> (206) 679-5933
>
> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Thursday, July 03, 2008 8:19 AM
> To: Schleiff, Marty
> Cc: www-tag@w3.org
> Subject: Re: Boeing XRI Use Cases
>
> Marty -
>
> I appreciate the effort that went into this.
>
> Probably the biggest roadblock preventing me from coming to terms with
> XRIs is the lack of concrete, comprehensible, and meaningful examples.
> (By "meaningful", I mean examples that illustrate why suggested
> alternatives are not adequate.)
>
> I wonder if you could add examples for (at least) these two sections
> (and perhaps more substantial examples for the other four sections):
>  - Fully Qualified Identifiers
>  - Identifier Types in Directories
>
> Thanks.
>
> --Ray
> ----- Original Message -----
> From: "Schleiff, Marty" <marty.schleiff@boeing.com>
> To: <www-tag@w3.org>
> Sent: Tuesday, July 01, 2008 5:55 PM
> Subject: Boeing XRI Use Cases
>
>
>
> Hi All,
>
> Ann Bassetti (Boeing's AC Rep at W3C) and I (a Boeing
> participant on the
> OASIS XRI TC) agreed it would be helpful to make Boeing use cases for
> XRI available for public discussion. Hopefully these use
> cases, together
> with ensuing discussions, will help resolve differences
> between the TAG
> and the XRI TC in their opinions about XRI. The use cases can
> be seen at
> http://wiki.oasis-open.org/xri/BoeingXriUseCases.
>
> Marty.Schleiff@boeing.com; CISSP
> Associate Technical Fellow - Cyber Identity Specialist
> Information Security - Technical Controls
> (206) 679-5933
>
>
>
>

Received on Friday, 11 July 2008 21:02:12 UTC