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