RE: [xri] Proposal: allow relative cross-references

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

Gabe,

Make no mistake, there is no reason to "codify the interpretation" of
cross-references as described, since that interpretation is one that may
only be needed in certain applications. I was just trying to illustrate
one example of where it would be very useful to have a relative
cross-reference.

As far as declaring *what* the relative cross-reference value is
relative too, I think that's easy. It's either:

1) If contained in another XRI, a relative cross-reference is is
relative to the parent node in the containing XRI. For example, in the
XRI "xri:@foo.bar.baz.(../egads)", the relative cross-reference
"(../egads) is relative to the node "@foo.bar.baz".

2) If the relative cross-reference is standalone, then it is relative to
the current context (just like with any other relative XRI). Example:
xri:(.foo) is relative to the current context.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Monday, September 22, 2003 10:21 AM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Proposal: allow relative cross-references

Drummond-
        I gotta say I don't totally follow your use cases, but I'm not
really concerned since the proposal seems relatively straightforward and
doesn't complicate the syntax or parsing of XRIs. I'd be a little
hesitant to codify the *interpretation* of cross references as described
here because a) its rather involved b)it could be different for
different uses of XRIs (ie different resource types) and c) its not
neccesary to build XRI resolvers and parsers. 
        So if the sole proposal is the one change to the BNF, then +1.
Are we sure there aren't any other effects? Normalization? Do we want to
declare *what* the xri relative value is relative *to* (did you do this
here?).

        -Gabe

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@onename.com]
> Sent: Friday, September 19, 2003 10:14 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Proposal: allow relative cross-references
>
>
> 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.
> 
> 
>
> To unsubscribe from this mailing list (and be removed from
> the roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/xri/members/leave
> _workgroup.php.
>