[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Significance of trailing delimiters (was RE: Describing vs Described problem)
|
Bill, I renamed this thread again since
you bring up a very precise issue that I believe needs to be addressed in the
context of the XRI resolution spec. I would propose that the question about
the signficance of a single trailing delimiter is that *from the standpoint of XRI resolution*
there is no difference. In other words, because there is no
addition segment or subsegment to resolve, there is no additional resource identified,
and thus no affect on resolution. To be specific, this would mean that all
of the following would return the same XRID from the same authority: xri:@foo*bar xri:@foo*bar/ xri:@foo*bar? xri:@foo*bar# Note that I specifically limited this
proposal to a single trailing delimiter. I don't think this rule can be applied
when there is more than one trailing delimiter, for the reason that second delimiter
may carry in fact define either: a) an explicit empty subsegment (e.g.,
"xri://@foo*bar//"), or b) a valid character in the XRI component
type (e.g., "xri://@foo*bar#?", where the ? may be interpreted as a
fragment value). Again, this is just a proposal, on a
subject that I think does need to be clarified in Res CD02. =Drummond From: Barnhill William
[mailto:barnhill_william@bah.com] Gabe, Ok, thanks. I can see your point
about a lot of this stuff being out of scope of the XRI, and am totally
comfortable with implementers deciding and seeing what works. I had thought
some of these things (like XRI resolution into the XRID doc, and a standard $
word for top level metadata) would be XRI scope, and my apologies for getting
confused. I agree on picking one conceptual model and moving on. As I
understand the two models I think either way will work, as long as everyone is
on the same page and it's clearly spelled out in the spec. I've had a view
of the authority segment being a reference to the controller of
the data (i.e authority) and the path being a controller specific address into
the controlled data, but I can see the case for the authority segment
representing a resource that is a resource of type XRID
publisher and of type xyz. One other question, and if out of scope, or done to death
already, then feel free to respond offline: Given xri://@foo*bar, does that have an implicit path of /
(making it really xri://@foo*bar/), and does that make it different than
@foo*bar, as previously discussed? I'd think the idea of an implicit path of /
if no path specified would be a good thing, no? On the same note is it within
XRI scope and is it specified what the difference, if any, is between the
following: xri://@foo*bar/baz xri://@foo*bar/baz# xri://@foo*bar/baz? xri://@foo*bar/baz#? xri://@foo*bar/# xri://@foo*bar/? xri://@foo*bar/#? Please let me know if any of the above are not valid XRIs.
By the difference I mean MUST they all resolve to the same resource. I realize
that most of the above are farsical and not likely to be encountered, but I can
see such XRIs being created, especially by a service provider that uses dynamic
XRIs that it creates from state information. On the subject of cliches (and implementers), "Plans generally
survive for five minutes after the battle starts, if that" (I think Patton
was source, but not sure). Thanks, =Bill.Barnhill From: Wachob,
Gabe [mailto:gwachob@visa.com] Bill- Thanks for asking these questions! BUT *I'M* getting confused. There's a lot
here that I don't think the XRI TC needs to speak to. I think generally the answer is that you
can do all of the things you propose, Bill, and we (the XRI TC) shouldn't
really care.
Well, I thought the pushback to my
reconceptualization was (well, Drummond agreed, at least) that an XRI
authority can identify *anything* (in essence, an XRI authority is just a
degenerate XRI in that sense). It resolves into an XRID that describes possibly
the resource identified by the authority, as well as services (such as
authority subsegment resolution) hosted on behalf of that authority by some
network endpoint. So Drummond's response to you confuses me since it seems to
be more in line with my reconceptualization than the pushback. I actually don't care too much at this
point - we need to decide and move on.
I think all of this is out of scope
of the XRI resolution spec. I think people will use XRIs in different ways and
we'll find out with use what works best. In fact, the XDI TC is proposing one
way to use XRIs that answers many of these questions and I think other
efforts at the same layer of XDI will be seen. <cliches> Let a thousand flowers bloom. Throw some
spaghetti on the wall and see what sticks. Survival of the fittest. Only
the strong survive. Veni vidi vici. </cliches> I wish I could always make my point by
throwing out a list of cliches... -Gabe |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]