[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Integration with Enterprise Directory Services
> > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]