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



Don't know if anyone still remembers this thread, but the issue has been fixed now. This means the OpenXRI server is now able to capture the fact that two or more of its root namespaces are synonyms. This was missing before.

The original motivation of the thread was that I had two synonym i-names @free and @on-line, and I wanted to be able to do the following:
1) For a given authority in the OpenXRI store, find all known fully qualified XRIs that resolve to it. For example, if I add *x under the authority of @free, I wanted to get the information that it is also resolvable as @on-line*x
2) Bind an i-service to an authority instead of to a single i-name, without using CanonicalIDs. For example, I wanted to set up a shared Contact Page for both @free*x and @on-line*x, without having to change the Contact Page configuration every time I add a synonym.

Both is possible now. Will upload the new version to @freeXRI later today...

Markus

On 5/10/07, Drummond Reed < drummond.reed@cordance.net> wrote:

I think I see what you are driving at, Marcus. I agree that OpenXRI needs a method for adding another namespace with authority 1. This is consistent with the Draft 14 ABNF (http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1 ), which clarifies that both @free and @on-line are themselves subsegments (in the GCS namespace) that could be associated with the community namespace.

 

=Drummond

 


From: markus.sabadello@gmail.com [mailto: markus.sabadello@gmail.com] 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: [xri] 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

 


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