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: Thoughts about XRI aliases


Hi all,

Sorry for posting this to both the XRI TC and OpenXRI lists, I don't know where it fits.

Concerning aliases, I ran into situations on which I would like to hear someone's opinion. With aliases I don't mean <Ref>s or <CanonicalID>s, but simply different XRIs that resolve to the same authority.
 
----- Setting the stage:
Assuming I have registered the i-name @free at some i-broker. Now I want to use OpenXRI to host the community i-name @free*x. This is what I do:
1) At my i-broker I configure the XRD of @free appropriately.
2) I put a namespace called @free into my OpenXRI store.
3) Then I put a new authority and a subsegment called *x under the @free namespace into the store - easy.

Assuming further I want to host another community i-name called @free*y, which I want to be an alias for @free*x, i.e. resolve to the same XRD and share all i-services. This is what I do:
1) I put a subsegment called *y under the @free namespace, with the same authority as *x, into the store - easy.

This works fine, OpenXRI even generates <LocalID>s automatically when the XRIs are resolved.

----- 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]