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

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

Exactly. Well put, Loren (I wish I'd put it that simply to begin with).

=Drummond 

-----Original Message-----
From: Loren West [mailto:loren.west@epokinc.com]
Sent: Wednesday, September 24, 2003 8:53 AM
To: Drummond Reed; 'Wachob, Gabe'; xri@lists.oasis-open.org
Subject: RE: [xri] Proposal: allow relative cross-references

Hi Drummond,

I understand cross references to mean: "the resource that XX
refers to as YY".  In as much as you can refer to XX in a
relative way, I can see the value of relative cross references.

=Loren

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@onename.com]
> Sent: Tuesday, September 23, 2003 6:16 PM
> To: Wachob, Gabe; xri@lists.oasis-open.org
> Subject: RE: [xri] Proposal: allow relative cross-references
>
>
> 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.
> >
>
> 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.