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


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

 



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