Note on normailization/comparison

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

Dave, in re-reading my message I just realized that in the BNF we make
the implicit assertion that "/" and "/." are equivalent, yet we don't
mention this in the Normalization/Comparison section.

I think in that section we should say something like, "All dots
following slashes should be removed as part of normalization prior to
comparison".

What do you think?

=Drummond

-----Original Message-----
From: Drummond Reed 
Sent: Wednesday, July 02, 2003 6:40 PM
To: Wachob, Gabe; Dave McAlpin; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] Interpretation of "relative XRIs"

A comment and a proposal:

1) +1 on Dave's answer: 2396 relativity (this is starting to sound like
a physics textbook ;-) i.e., context-relativity, should be what we mean
when we talk about a "relative XRI",. The * gcs character is a new
concept in relativity (general relativity? ;-) in which the XRI
following the * char is relative to a user-defined context, not to the
current context.

2) Relative to Gabe's question: " Why would "xri:@foo" + "bar" make
"xri:@foo/bar" ? Why not "xri:@foo.bar"? Is the insertion of the "/"
specified in 2396?"

I'll leave it to DaveM to answer about 2396, but the larger issue I want
to point out is that XRIs offer four hiearchical path delimiters (dot,
colon, slash-optional-dot, slash-colon) rather than the one (slash) in
2396.

The latter two (slash-optional-dot, slash-colon) are already compatible
with the [dot] dot slash 2396 relative path syntax. I.e. you can write
the relative XRIs:

            ./foo.bar (which is equivalent to ./.foo.bar)
            ../foo.bar (which is equivalent to ../.foo.bar)
            ./:foo:bar
            ../:foo:bar

So if we want relative XRIs to support all four types of relationships
between the relative reference and the base XRI, the only two we'd need
to add are support for dot-relative or colon-relative XRIs.
Colon-relative is easy; it could just be

            .:foo:bar
            ..:foo:bar

Dot-relative is a little tricker because it can be ambiguous with the
dots that delimit the relative XRI. A simple solution would be to use a
semicolon as a replacement for the leading dot in relative XRIs. So
you'd have:

            .;foo.bar
            ..;foo.bar

This approach would also work for "climbing the ladder" as far up as you
wanted to go in the hierarchy. For example:

            ../../foo             slash-parent of the slash parent of
foo (dot or colon)
            ..:..:foo              colon-parent of the colon parent of
foo
            ..;..;foo             dot-parent of the dot parent of foo
            ../..;foo             slash-parent of the dot parent of foo

and so on with any mix or match to any number of levels you want.

I know it's more options that we would like, but it's as logically
complete as the relative URI conjunction rules, and it enables
expressing the full range of identifier relationships allowed in XRIs.

=Drummond

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Wednesday, July 02, 2003 2:00 PM
To: 'Dave McAlpin'; Wachob, Gabe; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] Interpretation of "relative XRIs"

I'd really like the 2396 interpretation to be the case. I just wanted to
make sure.

So the * gcs really is the "use default naming authority" and the
relative xri form is really the 2396 meaning, which I interpret (like
you) to basically mean that to get a "non-relative" xri from a relative
XRI, you syntactically append something before the relative XRI. Where
that "something" comes from is defined generally in 2396 (but ends up
depending on how you got the relative XRI in the first place).

Great, fine. Just needed clarification and amplification. I want this
specifically said in the spec!

    -Gabe

P.S. Why would "xri:@foo" + "bar" make "xri:@foo/bar" ? Why not
"xri:@foo.bar"? Is the insertion of the "/" specified in 2396?
-----Original Message-----
From: Dave McAlpin [mailto:dave.mcalpin@epokinc.com]
Sent: Wednesday, July 02, 2003 1:56 PM
To: 'Wachob, Gabe'; xri-editors@lists.oasis-open.org
Subject: RE: [xri-editors] Interpretation of "relative XRIs"
I understood relative in exactly the same sense as it's used in 2396. If
you have a relative reference "bar" and a base XRI "xri:@foo", how to
you convert the relative reference into the fully qualified XRI
"xri:@foo/bar"? That's the question I'm attempting to answer. Is that
not what you have in mind Gabe?

Dave

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com]
Sent: Wednesday, July 02, 2003 1:48 PM
To: 'xri-editors@lists.oasis-open.org'
Subject: [xri-editors] Interpretation of "relative XRIs"

I still think I don't quite follow the rules w/r/t to "relative" XRIs.

Is it fair to say that a relative XRI is simply one that doesn't specify
the naming authority in which it is defined? So, for example, the way to
"resolve" a relative XRI is simply to have a "default" name authority in
your resolver?

If so, how is this different from the * GCS

I'm still concerned about our use of "relative" in this case. This is
different from "relative" in the URI sense, I think, in that, in
2396land, a relative URI is relative to the context in which it is
presented (ie an HTML file, a MIME wrapper, etc, or in a document with
XML Base data). We mean something else by "relative" - its not relative
to the context in which the relative XRI is presented - its relative to
the client resolver!

If this is true, I would really like to not call this "relative", or at
least call it "client-relative" or something more specific.

On the other hand, if I'm still not getting relativity, it could use
more description (and I know its marked as being on Dave's plate to
describe).

    -Gabe

---------------------------------------------------------------------
To unsubscribe, e-mail: xri-editors-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xri-editors-help@lists.oasis-open.org