OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[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]