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



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