[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [Openxri-users] Thoughts about XRI aliases
My rant didn’t make it to the XRI
list, so I’m resending it here. Markus, please do not think that I’m
directing my venom here at you. (They know who they are. J) ~ Steve From: Steve Churchill
[mailto:steven.churchill@ootao.com] Markus and all, The XRI authority graph model is neither
fuzzy nor ambiguous. On the contrary, it is formal and verifiable. [The
problem, for everyone, is that we have left the graph model to be reverse
engineered by the audience of the XRI Resolution Spec, but more about that
below.] Consider this example: I can set my XRD
for =steven.churchill so that its $res*auth SEP points to the same URI as does
the $res*auth SEP for @free. If I do this, then =steve*<name> will
successfully resolve for any <name> in @free’s namespace. (You can
try this little exercise to see if I’m lying.) The important thing is that all this type
of crap just doesn’t matter! The XRI authority graph resulting from this
little exercise is not verifiable, and thus whatever results from XRI
resolution is just “noise” in the XRI space. But if you
don’t look at the problem from a graph perspective, then it becomes
really hard to see this. I repeat (to everyone in this TC) if you don’t
look at the problem from a graph perspective, then it becomes really hard to
see this. Conversely, if you look at XRI authority
resolution from the standpoint of having a formal graph model, then the only
questions are “what is the definition of the graph” and “how
is a valid graph verified”. This is well defined and formal. You can read
about it in my articles on CanonicaIID verification at http://dev.inames.net/wiki/XRI_CanonicalID_Verification. Markus, I suggest that you look at your 3 questions
from the perspective “do these scenarios result in verifiable XRI
authority graphs?” If you do (and once you are familiar with the graph
model) then I think you will see that the fuzziness goes away. ~ Steve PS: Drummond, the confusion of this thread
arises largely because we HAVEN’T formalized the authority graph model in
the XRI resolution spec. Again, we are forcing the abstract model to be
reversed engineered from the specification. Very bad. To answer questions such
as Markus’s outside of the context of the formal XRI graph representation
is mostly an exercise in confused terminology and wasted time (such as this
thread.) But alas, I’ve complained about this on several occasions to no
avail. From:
openxri-users-bounces@lists.sourceforge.net
[mailto:openxri-users-bounces@lists.sourceforge.net] On Behalf Of Markus Sabadello Question 3: A "namespace" in OpenXRI terms is an entry point into
the realm of the store. Its authority lies outside the store (e.g. still at the
i-broker), but it can act as a parent authority inside the store. In contrast,
a "subsegment" in OpenXRI terms has both a parent authority and an
authority inside the store. So if I host @free*x at my OpenXRI server, then I have the following
things in my store: - The namespace @free associated with an authority 1 - The subsegment *x with parent authority 1 and authority 2 In total one namespace, one subsegment, and two authorities. Now If I want to register @free*y as an alias for @free*x, I simply put
the following in the store - The subsegment *y with parent authority 1 and authority 2 But I can do nothing to tell my store that it is also responsible for
@on-line*x and @on-line*y. For that I would need a method to associate another
namespace with authority 1. Markus On 5/10/07, Gabe
Wachob <gabe.wachob@amsoft.net>
wrote: You ask good questions. These are explicit design
requirements that many people have forgotten about. Answer to Question 1: Nothing wrong – this is totally
anticipated. I don't know that we have a term, but yours seems OK. Answer to Question 2: Nothing wrong – this it totally
anticipated. The name sounds fine. Answer to Question 3: I don't understand the
difference between namespaces and subsegments – each subsegment defines a
new namespace… so maybe there's something else here?
But
before I do this, I would like to hear someone's opinion. Bill?
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]