[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: No Subject
And when we discussed this, we both realized that we already had a major feature of XRI syntax devoted to just this purpose: cross-references. The entire purpose of a cross-reference is to enable a globally-unique identifier to be shared across two or more contexts for the purpose of establishing equivalence across those contexts - those contexts being established by the XRIs containing the cross-reference. For example the XRIs "xri:@foo/(+bar)" and "xri:@baz/(+bar)" enable the globally-unique identifier "+bar" to be shared across the contexts "@foo" and "@baz", which is tremendously useful because it allows "@foo" and "@baz" to assert the logical equivalence of two separate resources in their respective domains. For this reason the embedded cross-reference is inherently treated as opaque and non-resolvable, because its only purpose is to establish equivalence. Since thjs is also the only purpose of a non-resolvable XRI, Gabe and I realized that the obvious syntax for asserting that an entire XRI is non-resolvable is to simply treat the entire thing as a cross-reference, i.e., a "global cross-reference". So xri:(anyXRIvalue) means "anyXRIvalue" is to be treated in the context of THIS XRI (meaning whatever context the author embedded THIS XRI) as non-resolvable and used only for equivalence. Furthermore, it also makes it obvious that the value of a non-resolvable XRI is equivalent to the value of the same XRI if it was resolvable, i.e., "xri:(anyXRIvalue)" is equivalent to "xri:anyXRIvalue", because the very purpose of a non-resolvable XRI is to establish this equivalence. Specific examples: xri:(@foo.bar/baz) ;is equivalent to "xri:@foo.bar/baz" xri:(//www.example.com/:1234:56/:780 ; is equivalent to "xri://www.example.com/:1234:56/:78" xri:(urn:isbn:some-isbn-number) ;is equivalent to "xri:urn:isbn:some-isbn-number" It turns out this solution has the additional benefit of being somewhat intuitive to English-speakers because it mimics a similar solution in English prose, as pointed out by David Booth in the paper we referenced in the XRI Requirements doc (D. Booth, Four Uses of a URL: Name, Concept, Web Location, and Document Instance, http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm, January 2003.). When one wants to refer to the identifier of something vs. refering to the thing being identified, one puts the identifier itself in quotes. Examples. Bobby thought that "the doctrine of Mary" was something that Mary took way too seriously. It turns out that "the bug" was in fact a cockroach that had crawled into the computer. What many people call "hard-headedness" is in fact sometimes a virtue. One reason for the quotes is that the writer needs to be able to delimit the entire identifier (which may be more than one word) in the context of the surrounding sentence. That's exactly what we are doing with the parens that delimit a cross-reference. So, in conclusion, in the 07 Working Draft Gabe and I are proposing that the use of the "!" character be dropped in favor of the simple mechanism of being able to assert the non-resolvability of any XRI by making the entire XRI a cross-reference. =3DDrummond=20 -----Original Message----- From: Drummond Reed=20 Sent: Friday, July 18, 2003 10:01 AM To: xri@lists.oasis-open.org Subject: RE: [xri] Formal proposal on non-resolvable XRIs Based on some off-list feedback that using "$" by itself to indicate non-resolvability could be confusing because it overloads the meaning of $ (esp. because everything else in the $ space uses at least one char after the $), I'm modifying my proposal. The modified proposal is to use "$$" for non-resolvability, i.e., that the char following the $ authority char to indicate that "the following XRI value is non-resolvable" is a second $. The same equivalence rule applies, i.e., the XRI value following "$$" is equivalent to the same XRI value without the $$ prefix. Examples: xri:$$/(@foo.bar/baz) (is equivalent to "xri:@foo.bar/baz") xri:$$/(//www.example.com/:1234:56/:78) xri:$$/(urn:isbn:some-isbn-number) xri:@foo.bar/($$/(//www.example.com/:1234:56/:78)) Again, if there are any objections/counterproposals, please respond ASAP as this is being written into the 07 draft as we speak. =3DDrummond -----Original Message----- From: Drummond Reed Sent: Monday, July 14, 2003 8:34 PM To: xri@lists.oasis-open.org Subject: [xri] Formal proposal on non-resolvable XRIs Having noodled over last week's discussions, here's a formal proposal to close the non-resolvability issues in the 07 draft. The proposal is that we drop the the use of the "!" character as the indicator for non-resolvability, and also drop this as an XRI reserved character. (This brings the delta between the URI reserved character set and the XRI reserved character set down to four chars - left paren, right paren, dot, and star.) This also eliminates the issues around the "!" character not falling cleanly into the 2396 URI component buckets. In place of "!", we define "$/" as the special metadata that identicates "the following XRI value is non-resolvable in the context of this XRI". Like any XRI identifier space, if the XRI value following "$/" is global (rather than local), it must be enclosed as an xref. Lastly, we specify that the $/ is ignored for purposes of establishing equivalence between two XRI values. Examples: xri:$/(@foo.bar/baz) (is equivalent to "xri:@foo.bar/baz") xri:$/(//www.example.com/:1234:56/:78) xri:$/(urn:isbn:some-isbn-number) xri:@foo.bar/($/(//www.example.com/:1234:56/:78)) Note that the last example is (IMO) redundant and not recommended because nested xrefs should always be treated as opaque in the context of the enclosing XRI. Although they may be resolvable *on their own*, in the context of the enclosing XRI they are only used to establish a shared identifier. "$/" is proposed because a) it's short, and b) it seems like a logical meaning for the standalone meaning of this character, because the $ space is intended for identifier metadata that will, as a rule, not be resolvable, but can only be interpreted in the context of the XRI specification. Please post any problems/counter-proposals by Thursday or we'll go with this in the 07 draft. =3DDrummond You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup .php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup .php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]