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] Re: [Openxri-users] Thoughts about XRI aliases


 

Markus,

 

These are all good questions that you ask. Keep ’em coming. My comments in ###.

 


From: markus.sabadello@gmail.com [mailto:markus.sabadello@gmail.com] On Behalf Of Markus Sabadello
Sent: Friday, May 11, 2007 8:31 AM
To: Steve Churchill
Cc: Gabe Wachob; openxri-users@lists.sourceforge.net; xri@lists.oasis-open.org
Subject: [xri] Re: [Openxri-users] Thoughts about XRI aliases

 

Hey :)


Noone is saying that anything about the XRI graph model is fuzzy or amibuous.. But you're right that I had to reverse engineer my knowledge about it from the resolution specs. I just read your "xri-polyarchy-article.pdf ", and I understand and totally agree with everything that's written there. The graphs are wonderful, I think something like that should be in the WD11 spec.

 

One of the main problems with the OpenXRI server is that it currently has no support at all for CanonicalID and i-numbers. Instead it uses stupid-looking URNs to identify authorities.

###  Conceptually, a given instance of the OpenXRI server hosts a subgraph of the entire authority resolution graph. If you want the OpenXRI server to be capable of hosting subgraphs that validate under CID verification, then it needs to be capable of producing XRDs containing <CanonicalID>s that have a delegation path up to one of the GRS roots. If the OpenXRI server is not capable of hosting CID-verifiable subgraphs, then I would challenge its usefulness.

 

Another problem in the OpenXRI server (and in my way of thinking) may be the term "aliases". Please let me know if the following is consistent with the XRI synonym mechanisms: For example, it is possible with OpenXRI to set up @free*a*b and @free*x*y*z and @free*c and @free*d to all share the same authority and therefore all SEPs. But no <Ref> is involved in any of the XRDs here. So the OpenXRI server can basically model a polyarchical relationship without <Ref>s. Is this behaviour incorrect? I am beginning to think that this is wrong.

### Under CID verification, XRI’s @free*a*b and @free*x*y*z and @free*c and @free*d cannot return an XRD with the same CID, unless they use Refs. Thus the XRIs CANNOT be synonymous under CID verification. (The word “alias” seems to be another synonym for “synonym”. The XRI Resolution Spec should (Drummond) define the word “synonym” in order to avoid this confusion.)

 

Despite all this, I am still saying (as in my first mail) that a piece of information is missing in the OpenXRI store and that there needs to be a way of telling OpenXRI that two namespaces (i.e. root authorities from OpenXRI's point of view, such as @free and @on-line) share the same authority.

###  As I mentioned above, they cannot share the same authority under CID verification without using a Ref. [As I mentioned in my previous “bitch” email, they can always share the same authority by setting the $res*auth SEP URI for @free to the corresponding value in @on-line, but such a graph is not cid-verifiable. Gabe and I disagree as to whether such graphs are “noise” are not.]
 

If you don't agree with that, tell me how to solve these 2 problems:

###  Markus, if you still have issues after the above, then please re-ask the questions, and I will respond.

 

1) I-services: The contact page specification says that a contact page can either be bound to an authority or to a QXRI. On freexri, both is possible. So I decide to set up an authority-bound contact page for @free*x. Now someone tries to access @on-line*x. How does my contact page i-service (which has access to my OpenXRI store) look up the right contact page? I know, the correct way would be to perform XRI resolution on @on-line*x and look at the CanonicalID. But this is overkill, since I already know that @free and @on-line share the same authority, and if there was a way of configuring my OpenXRI server to "know" this, then I could simply look into the store and conclude that @free*x and @on-line*x are the same.

 

2) For a given QXRI that resolves to an authority in my store, I want to find other QXRIs that also resolve to it. This works fine for @free*x and @free*y, since the store knows that *x and *y share the same authority. But how do i know that @free*x and @on-line*x share the same authority? Again, there needs to be a way to add the information to the OpenXRI store that its "root authorities" @free and @on-line are the same.

 

Markus

 

P.S.: If anyone wants to look into the details of the OpenXRI store, I can of course give you mysql access to the freexri database.

 

On 5/11/07, Steve Churchill <steven.churchill@ootao.com > wrote:

 

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
Sent: Thursday, May 10, 2007 2:01 PM
To: Gabe Wachob
Cc: openxri-users@lists.sourceforge.net ; xri@lists.oasis-open.org
Subject: Re: [Openxri-users] Thoughts about XRI aliases

 

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?

 

 


----- Now Question 1:
I want to host another community i-name called @free*x*z ! This is what I do:
1) I put a new authority and a subsegment called *z under the authority of *x into the store.

Now a funny thing happened. Since @free*x and @free*y are aliases, they also share their authority resolution SEP.
Which means that @free*x*z is also resolvable as @free*y*z

Questions: Is anything wrong with that? Is there any name for this? Would it be appropriate to call @free*x*z and @free*y*z "inherited" aliases?



----- Now Question 2:
I am hosting a community i-name called @free*a. Now I want to host another community i-name called @free*a*b, which I want to be an alias for @free*a ! This is what I do:
1) I put a new subsegment called *b under the authority of *a, with the authority of *a into the store.

Now even more funny things happened. Since @free*a*b and @free*a are aliases, they also share their authority resolution SEP. @free*a*b 's own authority and parent authority are the same.
Which means that @free*a*b is also available as @free*a*b*b, which is also available as @free*a*b*b*b*b*b*b*b*b*b, etc.

Questions: Is anything wrong with that? Is there any name for this? Would it be appropriate to call them "recursive" aliases?

----- Now Question 3 (OpenXRI-specific):
Assuming I have registered not only the i-name @free, but also @on-line, which is an alias for @free.
Therefore, if I host a community i-name called @free*m, it is also resolvable as @on-line*m ("inherited" alias).

>From my OpenXRI server's point of view, @free and @on-line are "namespaces" or "root authorities". If I want to work with both, I need to put both into the OpenXRI store.

But here's the problem: While the OpenXRI server can cope well with aliases among its subsegments, it currently has no way of capturing the fact that two of its namespaces are aliases. If, for example, I set up a Contact Page i-service at @free*m, it will not work for @on-line*m, since OpenXRI cannot find out that they are the same.

I therefore propose to make the appropriate changes to the OpenXRI server. We currently have these methods in the Store interface:
    public Authority createRootAuthority(String namespace);
    public void deleteRootAuthority(String namespace);

I propose to replace this with the following:
    public Authority createNamespace(String namespace);
    public void deleteNamespace(String namespace);
    public void createAliasNamespace(String namespace, String aliasNamespace);
 

But before I do this, I would like to hear someone's opinion. Bill?


I further believe that to be 100% correct, changes to the URIMapper interface would be necessary. The URIMapper is responsible for interpreting incoming requests and currently tries to extract a namespace from an incoming URI, but it would be slightly more correct to extract a root authority id instead. However this is of low priority I think.

You can try everything I wrote here at www.freexri.com

-Markus

 


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Openxri-users mailing list
Openxri-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxri-users

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]