[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02)
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] Sent: Wed 11/2/2005 1:18 PM To: Barnhill William; Drummond Reed; xri@lists.oasis-open.org Subject: RE: [xri] RE: Describing vs Described problem (was Compromise Conceptualization Towards CD-02) 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]