Integration with Enterprise Directory Services

[Drummond Reed]

> > Drummond Reed wrote:
> > Yes, Marty Schleiff at Boeing is working on an RFC for how to represent
> XRIs
> > in an LDAP directory for that very reason -- to establish standard OIDs
> for
> > this attribute. LDAP already has a URI attribute type, but downcasting
> an
> > XRI into a URI just to squeeze it into that attribute type loses the
> > semantics that the XRI is an abstract identifier for the resource. So
> Boeing
> > wants to establish OIDs for primary-xri (value of the canonical XRI) and
> > alt-xri (value of any other XRI synonym).
> >
> 
> Martin Atkins wrote:
>
> This is perhaps a bit of a tangent, but what are the disadvantages to
> representing XRI as a URI? It seems to me that having two completely
> orthogonal sorts of identifier rather than having one be a "subset" of
> the other just makes things needlessly complex. What makes you consider
> XRI to be an "abstract identifier" but a URI not to be?

Mart, to clarify: after the transformation defined in the XRI spec, an XRI
is a valid URI the same way an IRI, after the transformation defined in the
IRI spec (RFC 3987) is a valid URI.

Both XRIs and IRIs had good reasons to define syntax that, before the
transformation, is not valid URI syntax because both add features not
supported in URI syntax. In IRI's case, it was support for internationalized
characters. In XRI's case, it was support for structured identifier syntax
that is particularly useful for abstract (vs. concrete) identifiers.

What makes XRI identifiers abstract is simply that this "branch" of the URI
family has been defined explicitly for abtract identifiers (i.e.,
identifiers which resolve into other concrete identifiers, vs. directly to a
resource location), and XRI infrastructure is being deployed for that
purpose. The same could be said of URNs: they are the "branch" of the URI
tree designed to meet the requirements of persistent identifiers, and URN
infrastructure has been deployed for that purpose. That doesn't mean every
URN is in fact persistent any more than it means every XRI is abstract, but
that's the intent.

> The whole thing of just starting with an equals sign is very cute, but
> surely that's just a shorthand to avoid writing "xri://" in contexts
> where it's unambiguous, much like people routinely write things like
> "www.google.com" when an "http:" URI is expected.

Yes and no:

"Yes" because the XRI specifications are very clear that if you cast an XRI
into an IRI or URI (which presumably you would if you wanted it to be
recognized as an IRI or URI), then you MUST add the "xri://" prefix.

"No" because the XRI TC realized that the pattern of not including scheme
name is not just an anomaly -- it represents a very common human usability
requirement that is now supported in popular text editors and other computer
tools on every platform. However the "www." convention is just that -- a
convention for meeting this usability requirement that is not formalized
anywhere. By contrast, the XRI TC put human usability explicitly in scope,
and felt that defining a clear and unambiguous specification for such
prefixes would ultimately lead to a much better user experience across the
vast variety of applications and contexts in which abstract identifiers may
ultimately be used. It was that requirement that led to the solution of
using "the simplest thing that could possible work" -- single-character
"global context symbols".

Net net: the fact that all absolute XRIs start with a global context symbol
not just a coincidence (or "cute" as you put it), but an explicit usability
design decision so that XRIs would be as unambiguous as possible in ordinary
text WITHOUT the need for a URI-conformant scheme name (which to the vast
majority of users is unintuitive and "geeky").

BTW, = is just one of four global context symbols -- the others are @ for
organizational identifiers, + for generic identifers, and $ for specified
identifiers. (In XRI Syntax 2.0, ! was defined as a both a local and global
context symbol, but its use a global context symbol is planned to be
deprecated in XRI 3.0.)

Hope this helps,

=Drummond