Proposal: allow relative cross-references

["Drummond Reed" <drummond.reed@onename.com>]

In the Visa feedback quoted at the end of this message, the question
"Why are cross-references only absolute?" was asked. This question has
come up again and again ever since the concept was first developed in
XNS and we've never had a good answer other than the one Gabe gave in
his reply, which is that we didn't really know what it would mean.
 
However, I've always felt that was a little bit of a dodge, because it's
actually clear what a relative cross-reference would mean: interpret the
cross-reference relative to the current node in the path (as identified
by the larger XRI in which the relative cross-reference was embedded)
just as any relative identifier is interpreted relative to the current
context.
 
It's just that this seemed silly in the context of a conventional
hierarchical-segment identifier because the parent of the current node
would be obvious from the path itself. However, because XRIs support
delegated identifiers (the dot and colon syntax) that can "jump" between
authorities, it is in fact entirely possible that the LOCAL parent of a
current node may not be known from the explicit XRI. Here's a simple
example. In the XRI:
 
               xri:@someplace/foo.bar.baz/something
 
...the node "bar" may not be the local parent of "baz", but may be the
identifier used by authority "foo" to delegate to authority "bar". Thus
the identifier "baz" may have a different direct parent in its own
authority space ("local parent"). If you wanted to point to the LOCAL
parent, you would use the relative cross-reference "(..)" meaning "go to
the parent node of the current node". The full XRI would be:
 
               xri:@someplace/foo.bar.baz.(..)/something
 
I've come across some use cases trying to describe ordinary directory
trees (like file systems) with XRIs in which this actually proves very
useful - in fact, just as useful as ".." ends out being in file paths
(where it is used a lot, especially in HTML file trees).
 
Furthermore, I've recognized another obvious use case for allowing
relative XRI values in cross-references. A month ago we concluded that
the easiest way to express "non-resolvable" XRIs was by enclosing the
entire thing in parens as a cross-reference, i.e., xri:(@foo). However
we didn't consider that one might need to do this with a relative XRI
value. Again, what would be the point?
 
Well, the point would be when one needs to refer to THE RELATIVE XRI
VALUE ITSELF and not to what it refers too. It's exactly the same as
with an absolute XRI. Say you have a list of relative XRIs in an XRI
directory that includes ".foo" and now you want to delete the identifier
".foo" from this list. You need a way to refer to THE IDENTIFIER ".foo"
and not THE RESOURCE IDENTIFIED BY ".foo". The obvious way to do this is
by using:"(.foo)".
 
Conclusion: I am now convinced that the Visa person's feedback was right
- cross-references should allow any form of XRI, not just absolute XRIs.
However there was one good syntactic reason that we allowed only
absolute values in cross-references, and that was that since a relative
reassignable XRI can start with any character including an ALPHA, and
URI scheme names start with an ALPHA, it could be ambiguous whether an
cross-reference value was a relative XRI or a URI starting with a scheme
name.
 
Despite the fact that 2396 URI syntax has this very same ambiguity (and
they chose to live with it, opting for "opportunistic resolution"), it
would be better if we didn't have to live with it. Thankfully, it turns
out that there is a simple solution to this. Whereas relative persistent
XRI values MUST start with a colon, relative reassignable XRI values
OPTIONALLY start with a dot. By simply adding the requirement that a
relative reassignable XRI value USED AS A CROSS-REFERENCE *MUST* include
the optional dot, we eliminate any syntactic ambiguity with a URI scheme
name.
 
Thus the formal proposal is to modify line 518 of the current EBNF to
replace "global-xri" with "xri-value" and eliminate line 519 (which is
no longer needed to define "global-xri".
 
Any objections, please do post promptly, as we need to incorporate this
change into the 08 draft under preparation.
 
Thanks,
 
=Drummond 
 
 
 
-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Thursday, August 28, 2003 4:06 PM
To: 'xri@lists.oasis-open.org'
Subject: RE: [xri] Draft -07 feedback from another Visa person
 
 
Initial responses to comments below:
---------
XRI Comments
 
340-341 Why are cross references only absolute?  For simplicity or
        conciseness?  Is this just a nomenclature issue?
        i.e. identifiers (relative, etc) satisfy local
        cross-referencing needs? 
Cross references are absolute mostly because its not clear what the
context for the identifier would be if it *weren't* absolute. That is,
if a relative identifier were used, then what root namespace would have
been defined in? 
 
I think there may also be some logical reasons having to do with the
motivations for cross references. That is, the purpose of a cross
reference is to use an identifier defined elsewhere in another
namespace/identifier community. Coming from "elsewhere" implies,
generally, that an identifier needs to be globally uniquely identified
-- thus the requirement of being absolute.