[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Note on normailization/comparison
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]