RE: [xri] Potential breakthrough

["Drummond Reed" <drummond.reed@cordance.net>]

Wil,

Agreed on all points except for two clarifications:

1) As much as you'll hate me for this, in the revised ABNF there is no
longer any rule called "global-xref". We just didn't need it any more (I was
as surprised as you are). Now the only difference between the 2.0 and 2.1
models is that where 2.0 had 2 subsegment types, 2.1 has seven. (I have to
believe that this means even if the abstract syntax is revised, the upgrade
can't be that hard -- you're parsing on six subsegment delimiters instead of
two subsegment delimiters, but otherwise everything else is identical.)

2) You say "this new concept does not make any claims about persistence",
but actually a subsegment that starts with a GCS symbol is completely
unambiguous about persistence. First, the global context symbol itself is
always persistent. If it is followed by a typeless subsegment (which would
only be parsed if the global context symbol was the start of the XRI), that
typeless subsegment is reassignable. To "keep" persistence going, you MUST
follow it with a persistent identifier, meaning a ! subsegment.

Examples:

	@ootao+west
		@		persistent
		ootao		reassignable
		+west		reassignable


	@!1234+west 
		@		persistent
		!1234		persistent
		+west		reassignable

	@!1234+!5678 
		@		persistent
		!1234		persistent
		+		persistent
		!5678		persistent


Hope this helps. Talk to you on the call tomorrow.

=Drummond 



-----Original Message-----
From: Tan, William [mailto:william.tan@neustar.biz] 
Sent: Wednesday, May 02, 2007 11:15 PM
To: Steven Churchill; Drummond Reed; xri@lists.oasis-open.org
Subject: Re: [xri] Potential breakthrough

Call me really slow, but I think I'm slowly coming to appreciate Steve's
point that we should start from first principles (abstract syntax or
abstract model) working ourselves down to the serialization format (abnf).

Not that we actually formally defined a 2.0 abstract model, but I believe
most of us have a common understanding of what it is.  In 2.0, we have a
hierarchy of segments, each containing a hierarchy of subsegments. The
subsegments can be either persistent or reassignable. That seems to suffice,
and you don't have to talk about xrefs at all even though they are
supported. We've done better than uri just by virtue of the fact that we
have an abstract model.

The concatenated syntax seems to be motivated by the goal to provide a
syntactic sugar at the concrete level, which has since caused a few more
light bulbs to go off in Drummond's head that it can be more useful than
being just a syntactic sugar. That's fine but we need to find out how it
fits into the 2.0 abstract model to see if it has outgrown that. What I'm
hearing from Drummond is that it definitely needs to extend the abstract
model because there is a new concept called "global-xref" which is kind of
global (GCS symbol used) but still is local (to its context). And this new
concept does not make any claims about persistence. It still sounds strange
to me even though at one point I thought I accepted it.

Running with Steve's idea, can we have different models that layer on top of
the basic 2.0 model that provides for richer types? So clients and servers
that subscribe to the basic model would compare based on the types in the
2.0 model, while richer clients such as XDI processor would base their
equivalence rules on the richer model, which has more types than the 2.0
model. Essentially, the rich client would treat the parse tree differently
than a 2.0 basic client.

I need to sleep over it, let's talk on the Cal tomorrow.


--
http://xri.net/=wil      

-----Original Message-----
From: "Steven Churchill" <steven.churchill@xdi.org>
Date: Wed, 2 May 2007 23:01:46 
To:"Drummond Reed" <drummond.reed@cordance.net>,<xri@lists.oasis-open.org>
Subject: RE: [xri] Potential breakthrough

  
Drummond: 
  
> For example, +west, +direction+west, @cordance+west, and @cordance*west
all 
> make very precise assertions about the context of the identifier “west”. 
  
But if we normalize these identifiers to the 2.0 abstract sytax
tree, then we get 4 different syntax trees: 
  
+west 
+direction*(+west) 
@cordance*(+west) 
@cordance*west 
  
Thus, to the client-of-the-parser, 2.0 abstract syntax seems to satisfy the
requirements of this use case. 
  
As far as my question from below: Can we identify a parser client who's use
case is not satisfied by the 2.0 abstract syntax? 
  
I still don't see the use case where 2.0 abstract syntax fails. I'm not
saying that it doesn't fail, I'm just saying I don't see yet where it fails.

  
~ Steve 
  
  
  
 
----------------
 From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Wednesday, May 02, 2007 7:31 PM
To: 'Steven Churchill'; xri@lists.oasis-open.org
Subject: RE: [xri] Potential breakthrough

 
 
 
Steve,
 
 
 
I think I explained that in my email last night. But I can sum it up in just
a few sentences:
 
 
 
1) The identifiers +west and *west are not equivalent because they each
express the identifier “west” in a different context.
 
 
 
2) The identifiers *(+west) and !(+west) are also not equivalent for the
same reason.
 
 
 
3) The identifiers +west, *west, *(+west) and !(+west) are also not
equivalent for the same reason. Specially, the last two express “a
cross-reference to the reassignable identifier +west in a local context” and
“a cross-reference to the persistent identifier +west in a local context”,
respectively.
 
 
 
4) In XDI RDF, to take just one application, XRI authors and users need to
be able to express/understand identifiers in both local and global contexts.
For example, +west, +direction+west, @cordance+west, and @cordance*west all
make very precise assertions about the context of the identifier “west”. To
force +west to be either *(+west) or !(+west) in any of the above
identifiers would change these assertions, not just for machines, but for
the humans that need to understand them. What’s worse, rather than making
complex things simple, they would force simple things to be complex. Given
that XDI RDF (among other applications) relies on very precise
identification of resources and contexts – that needs to be understandable
by both machines and people – 2.0 syntax doesn’t meet this requirement.
 
 
 
I hope this helps. I fully understand the amount work involved with rev’ing
an XRI parser to 2.1 syntax. (It’s worth pointing out that not all this work
is due to supporting direct concatenation – 2.1 involves other important
revisions too.)
 
 
 
=Drummond 
 
 
 
 
 
----------------
 
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Wednesday, May 02, 2007 3:22 PM
To: 'Steven Churchill'; 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Potential breakthrough
 
 
 
I wrote:
 
 
 
 
> To answer this question, I would ask the following: Can we identify a
parser 
 
 
> client who's use case is not satisfied by the 2.0 abstract syntax?
 
 
 
 
 
Drummon, bbviously, you have one in the form of the
XDI-RDF-processor-as-client. We should explore precisely why this use case
isn't satisfied by 2.0 abstract syntax.
 
 
~ Steve
 
 
 
 
 
----------------
 
From: Steven Churchill [mailto:steven.churchill@xdi.org] 
Sent: Wednesday, May 02, 2007 3:14 PM
To: 'Drummond Reed'; xri@lists.oasis-open.org
Subject: RE: [xri] Potential breakthrough
 
Drummond,
 
 
 
 
I think the best approach at this point is to address the 100 lb gorilla
issue head on:
 
 
 
 
 
100 lb gorilla issue: Should we be changing the 2.0 abstract syntax?
 
 
 
 
 
[Note that this question exists with or without the compact syntax, because
the compact syntax can be normalized, if we so decide, to the 2.0 abstract
syntax.]
 
 
 
 
 
To answer this question, I would ask the following: Can we identify a parser
client who's use case is not satisfied by the 2.0 abstract syntax?
 
 
 
 
 
[If we take the approach of working from the ABNF up, then we are still
going to need to confront the gorilla issue at some later time.]
 
 
 
 
 
~ Steve
 
 
 
 
 
 
 
 
 
 
 
----------------
 
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Wednesday, May 02, 2007 8:51 AM
To: xri@lists.oasis-open.org
Subject: [xri] Potential breakthrough
 
I have an internal maxim that I follow: if Steve tells me he’s got a problem
with something, and after three times trying to work it out with him, he’s
still got a problem with it, then I need to look at it very closely and see
if there’s a better solution.
 
 
 
I’ve worked long enough with Marty now to realize the same thing is true
with him.
 
 
 
So when both of them plus Wil are telling me something is too complex,
that’s one helluva strong signal.
 
 
 
So after yesterday’s thread, I looked closely at the requirements again and
thought about the key issue Steve has raised about how “sticky stars” makes
for funky synonym rules. This jibes with what Marty keeps saying about how
the original “compact syntax” was much simpler than “sticky stars”.
 
 
 
I have always been the one saying that we needed sticky stars. So I
revisited that assumption…and realized that in that area I too had been
stuck with a “2.0” filter on. I had been assuming that anything you could
express as a parenthetical xref (which is “opaque” to XRI resolution) had to
be something that was also equally “opaque” when expressed as a global-xref.
 
 
 
But it’s that assumption that leads both to most of the increased complexity
and the funky synonym problem. So if you drop that assumption and do as
Marty has been suggesting all along and simply treat all subsegments as
subsegments…
 
 
 
…everything works just fine.
 
 
 
To illustrate, take Steve’s @ootao+west*steve and @ootao*west*steve example.
The current 2.1 syntax proposal requires these parse into separate trees:
 
 
 
@
 
ootao
 
+west*steve
 
 
 
@
 
ootao
 
*west
 
*steve
 
 
 
But if you drop the requirement that global-xrefs need to be syntactically
opaque, they would both parse into the same trees, with the only difference
being the type of one subsegment:
 
 
 
@
 
ootao
 
+west
 
*steve
 
 
 
@
 
ootao
 
*west
 
*steve
 
 
 
The funky synonym problem goes away because all subsegments are subsegments,
and if @ootao wants to declare +west and *west as synonyms, it doesn’t
affect any other synonyms lower in the tree. But you still get the semantic
precision of @ootao being able to express that +west is intended to be a
generic dictionary identifier vs. *west a local name without any expectation
of cross-referencability.
 
 
 
So I tried to figure out if there was any other requirement – in XDI RDF or
anywhere else global-xrefs would be used – that would not be met if
global-xrefs were not opaque. I couldn’t come up with any.
 
 
 
If so, we could essentially have our cake and eat it too. The ABNF would get
significantly simpler, and we’d get all the semantic simplicity/richness of
direct concatenation, but without any of the pain of funky synonyms or
increase resolution complexity.
 
 
 
Frankly, I’m still trying to figure out why I was so stuck on “sticky stars”
(so to speak ;-). After all, Marty has repeatedly said things would be much
simpler without them. But then, sometimes when something’s stuck in your
head, it takes a real jolt to knock it out.
 
 
 
I’ll take a pass on the simpler ABNF that reflects all this as soon as I get
a break today – worst case I’ll try to have something published by tonight.
 
 
 
=Drummond