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] Questions regarding XRI Resoution as client of 2.1 abstract syntax



Drummond, 

Let's try one more stab at email, and then go to phone. 

"@" delegates to child authority "ootao" (CID=01).
CID=01 delegates to child authority "+home" (CID=01!01).
CID=!01!01 delegates to child authority "steve" (cid=01!01!01).

Certainly, I can easily set up authorities to do the above. My point is that
(if I were to do so) then there is no way to resolve the third child
authority.

Please correct me where I have strayed.

~ Steve

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Monday, April 23, 2007 6:33 PM
To: 'Steven Churchill'; xri@lists.oasis-open.org
Subject: RE: [xri] Questions regarding XRI Resoution as client of 2.1
abstract syntax

Steve, you're not missing anything. Think of it this way. What if the
delegation you started with was @ootao*(=steve)? And then you asked me how
=steve can delegate to *home? My answer would be the same: =steve can't
delegate to *home under his own authority -- that local delegation can only
be recognized in a cross-reference if @ootao delegates to the whole thing,
i.e., @ootao*(=steve*home).

However @ootao*(=steve) can delegate directly to @ootao*(=steve)*home
because both *(=steve) and *home are local-subsegs. And you can continue
that chain of local delegations as long as you want. But Once you delegate
to a global-xref, you can't go back to delegating locally in the first
namespace, because you've moved to another global namespace.

Feel free to give me a call to discuss -- it will be faster than email --
and besides I can roll that into the writeup assignment about the rules for
usage of local and global context symbols that I took as an action item at
the f2f last week (BTW, minutes of the f2f are underway and should be out
shortly).

=Drummond 


Unfortunately =steve can't do that. Only @ootao*(=steve) can control
delegation below @ootao*(=steve)

-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Monday, April 23, 2007 5:31 PM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Questions regarding XRI Resoution as client of 2.1
abstract syntax


Drummond,

My use case is very simple. There are 4 authorities. There is @ which has a
child ootao which has a child authority +west which has a child authority
*steve.

I think you are telling me that there is no way to resolve *steve. What am I
missing?

~ Steve


-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Monday, April 23, 2007 5:13 PM
To: 'Steven Churchill'; xri@lists.oasis-open.org
Subject: RE: [xri] Questions regarding XRI Resoution as client of 2.1
abstract syntax

Steve, once you've added a global-xref to an XRI authority segment, you've
moved from one global context (the original one established by the first GCS
symbol) to another. In this new global context, all local subsegments create
different global xrefs.

So if you created @ootao+west*steve, in XRI resolution you would get an XRD
describing +west*steve from the XRI authority @ootao. This could of course
be different from the XRD that @ootao provides for +west.

In 2.0, local delegation (to a local-literal or local-xref) was the only
option. In 2.1, global delegation (to another global-xref) is a new option.
Once you've delegated to a global-xref, the only way to further delegate is
via another global-xref. For example, if Steve is =steve or @ootao*steve,
the two options for delegation under @ootao+west would be:

#1:	@ootao+west=steve
#2:	@ootao+west@ootao*steve

Both parse to four top-level subsegments:

1)	@			global-literal
2)	ootao			typeless-literal
3)	+west			global-xref
4a)	=steve		global-xref
4b)	@ootao*steve	global-xref 

=Drummond 

-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Monday, April 23, 2007 4:14 PM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Questions regarding XRI Resoution as client of 2.1
abstract syntax


Drummond, this leads me to the following question:

Say that I have an authority identified by @ootao+west and that I add an
authority into its namespace named *steve.

Please show me the XRI that (when passed to a resolver) would end up
returning the XRD for *steve. [Remember, the resolver deals with top-level
subsegments only.]

Thx,

~ Steve



-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Monday, April 23, 2007 3:55 PM
To: 'Steven Churchill'; xri@lists.oasis-open.org
Subject: RE: [xri] Questions regarding XRI Resoution as client of 2.1
abstract syntax

Steve, sorry, my text may not have been clear. The resolver doesn't "do
anything different" when it encounters a global-xref vs. a local-xref -- to
a resolve they are both just subsegments. What I meant was that a
global-xref has a different structure than a local-xref or a local-literal.

For example, with the XRI =a*b*(+c)+d*e, the parse tree has 5 top-level
subsegments: 

#1:	=	global-literal
#2:	a	typeless-literal
#3:	*b	local-literal
#4:	*(+c)	local-xref
#5:	+d*e	global-xref

The only thing that distinguishes a global-xref from a local-literal or
local-xref is that: a) it starts with a GCS symbol, and b) "inside" it you
can have additional local-literal or local-xref subsegments. But from the
standpoint of the parser or a local resolver, it's just another subsegment,
much as a local-xref has always been just another subsegment even though it
has a parsable XRI or IRI inside the parens.

=Drummond 

-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Monday, April 23, 2007 2:39 PM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Questions regarding XRI Resoution as client of 2.1
abstract syntax


[Steve asked]
3.	Does the resolver algorithm distinguish between "global" and "local"
subsegments. [I would assume the answer is no. The resolver simply walks
down the list of top-level subsegment invoking the authority resolution
services.]

[=Drummond] Yes, the resolver just walks down the list of "top-level"
subsegs, but the resolver algorithm DOES distinguish between global-xref and
local-xref as shown in the ABNF. A global-xref is the GCS character plus
zero or one typeless subseg plus zero or more local subsegs.

[Steve] I don't understand. Say the resolver is walking the top-level
subsegments. What precisely does it do differently when encountering a
global vs local xref?

Thx,

~ Steve






-----Original Message-----
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Sunday, April 22, 2007 8:59 PM
To: xri@lists.oasis-open.org
Subject: [xri] Questions regarding XRI Resoution as client of 2.1 abstract
syntax


Drummond,

I have some questions regarding the proposed 2.1 abstract syntax and XRI
Resolution as client.

For the benefit of those on the list who haven't been steeped in XRI
Resolution, let me give some context. [Drummond, my questions are below.]
The resolver invokes the XRI parser which returns a syntax tree conforming
to the abstract syntax. During the "authority resolution" phase, the
resolver walks through the top-level subsegments of this tree passing the
name of the "next" subsegment to the authority resolution service of the
"previous" subsegment, until it gets to then end.

In the 2.0 abstract syntax, the subsegments had two types--persistent and
reassignable. The notion of persistence is simply a convention for authority
resolution services (their registries) as follows: If I pay my registry for
a "bang" (persistent) identifier, then my registry should not reassign that
identifier to someone else, even if I stop paying my bill.

In the proposed 2.1 abstract syntax, the subsegments have seven types. Here
are my questions for Drummond:

1. 	Does the resolver still walk through the top-level subsegments (that
is, passing the name of the "next" subsegment to the authority resolution
service of the "previous" subsegment) as described above? [I would assume
the answer is yes.]

[=Drummond] Yes -- but note that global-xrefs are a type of subsegment per
your question 3 below.

2.	Can authority resolution services now accept 7 types of query? [I
would assume the answer is yes.]

[=Drummond] Yes.

3.	Does the resolver algorithm distinguish between "global" and "local"
subsegments. [I would assume the answer is no. The resolver simply walks
down the list of top-level subsegment invoking the authority resolution
services.]

[=Drummond] Yes, the resolver just walks down the list of "top-level"
subsegs, but the resolver algorithm DOES distinguish between global-xref and
local-xref as shown in the ABNF. A global-xref is the GCS character plus
zero or one typeless subseg plus zero or more local subsegs.

4.	Are six of the subsegment types reassignable and only one (bang)
persistent (as per the definition above)?

[=Drummond] No. A GCS character by itself is persistent. Then each subseg
inside a global-xref is persistent or not depending on whether it begins
with a bang. So a global-xref is persistent if and only if each of its
subsegs is persistent. Examples:

XRIS WITH PERSISTENT GLOBAL XREFS
In #1 and #2, the global-xref beginning with = is persistent. In #3 and #4,
the entire XRI is persistent.

#1:	@example=!1234.5678.a1b2.c3d4
#2:	@example=!1234.5678.a1b2.c3d4!55
#3:	@!1000.2000.3000.4000=!1234.5678.a1b2.c3d4
#4:	@!1000.2000.3000.4000=!1234.5678.a1b2.c3d4!55

NON-PERSISTENT GLOBAL XREFS
In all four examples below, the global-xref beginning with = is not
persistent, because it does not consist of all persistent subsegments.

#5:	@example=example.2
#6:	@example=!1234.5678.a1b2.c3d4*some.subseg
#7:	@!1000.2000.3000.4000=example2!55
#8:	@!1000.2000.3000.4000=!1234.5678.a1b2.c3d4*some.subseg

5. 	If the answer to 3 above is "no", then why does the parser care
about sticky stars?

[=Drummond] See my answer to 3 above.


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