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: RE: [xri] Formal proposal on non-resolvable XRIs


Title:

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]