[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Formal proposal on non-resolvable XRIs
Marc-
This
gets to the heart of the issue. I *think* the mechanism we are talking in
this thread is really about the expression of intent *to* the user of an XRI
(*from* the creator of the XRI string): "Don't try to resolve this part of
the XRI, I don't mean it to be resolvable".
However, it seems to me that the term "resolvability" intuitively means something different to me. "Resolvability" is really a feature of the way the resolution system is deployed, not a feature of a particular XRI. That is, a particular part of the XRI is "resolvable" solely based on whether there is a appropriate directory somewhere that contains 'resolution' information for that part of the XRI. If there is no such directory entry, that part of the XRI is "unresolvable".
So, the term "resolvable" is a little confusing for me, and this is part of my pushback.
Assuming the "intent" meaning (which is not my intuitive understanding), I still have some pushback. Its not clear to me why we need to mark a part of an XRI as "don't even try to resolve this part". I gather there was some feedback from the XML.gov people (is that right?) that they in fact *do* want the "don't even try to resolve" syntax. I don't quite understand the use case, but I'll go along with the value of the requirement for now.
It seems to me, given the XML namespace use case you give, that we are *really* talking about a part-by-part nonresolvability (rather than only marking an entire XRI as nonresolvable). This seems to me to be best done on a part-by-part (e.g. parallel to "." and ":") marker. Partial resolvability leads to being able to extract parts of the identifier to "guess" things about the entire XRI - we see this all the time in the use of HTTP URLs: (if http://www.example.com/some/complicated.cgi?arg=1&arg3=2 doesn't work, at least we can go to http://www.example.com and see if there is some context there that can help.
I can think of a thousand ways to do this, and I want to do the Simplest Thing That Can Possibly Work (http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork). Thus, I really want us to focus here on what we are trying to do vs. what would be cool (and possibly complicated).
</rant>
-Gabe
P.S. My initial proposal is that the "nonresolvable" market gets attached after the '.' or ':' separator -- e.g. .! or :! So you'd have xri://example.com/namespaces/xml.!app1
> -----Original Message-----
> From: Marc
LeMaitre [mailto:marc.lemaitre@onename.com]
> Sent:
Friday, July 18, 2003 12:46 PM
> To: Wachob, Gabe; Drummond Reed;
xri@lists.oasis-open.org
> Subject: RE: [xri] Formal proposal on
non-resolvable XRIs
>
>
> Since I was the one who proposed the
original need for a way to
> recognize that XRIs convey that they refer to
non resolvable
> resources I
> will have a stab at commenting on
this....
>
> Is it possible for an XRI to include a reference
to a resource that is
> unresolvable without the XRI itself being
unresolvable? Put another
> way; can I have an XRI resolve to a
network resource if part
> of the XRI
> references (or cross
references) a non resolvable resource.
> If not then
> it seems to
me that we just need to notate the entire XRI as
> unresolvable. If YES
then the non-resolution syntax should be appended
> to each segment of the
XRI so that it becomes obvious which segments
>
resolve.
>
> An example of the motivation for this would be if
an XRI was used to
> identify an XML Schema using an XML namespace that
included the
> authority responsible for creating the schema but that
the
> segment that
> identified the schema did not resolve to a copy
of the schema on a
> network.
>
> Does this make
sense?
>
> marc
>
> -----Original
Message-----
> From: Wachob, Gabe [mailto:gwachob@visa.com]
> Sent: Friday,
July 18, 2003 3:29 PM
> To: Drummond Reed;
xri@lists.oasis-open.org
> Subject: RE: [xri] Formal proposal on
non-resolvable XRIs
>
> Hi
all-
> Back in town
last night, and I have some
> comments/questions on
>
this.
>
> 1) Does nonresolvability only apply to an entire XRI or to
a part? We
> have syntactic constructs that end up applying to the whole
XRI value
> (e.g. global community identifiers) and syntactic
constructs
> that only
> apply to "parts" (e.g. : or .). Its not
clear to me that a global
> community identifier is appropriately used
here, when perhaps we need
> something parallel to the '.' and ':'
characters
> 2) Use of the double $$ is ugly and subject to
errors.
> 3) Is the use case for this feature to "comment" xri
values?
> If so, then
> $$ is definitely ugly. We've got a lot of
fancy examples, but perhaps
> there's a more obvious answer if we focus on
exactly what the issue we
> are addressing is.
> Sorry for the late
replies, but I made a conscious effort to
> make this a
> real
vacation (which didn't last NEARLY long enough).
>
-Gabe
>
>
>
> > -----Original
Message-----
> > From: Drummond Reed [mailto:drummond.reed@onename.com
>
<mailto:drummond.reed@onename.com> ]
>
> 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.
> >
> > =Drummond
> >
> >
>
> -----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.
> >
> > =Drummond
>
>
> > You may leave a Technical Committee at any time by
visiting
> > http://www.oasis-open.org/apps/org/workgroup/xri/members/leave
> <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
<http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgrou
p.php>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]