[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Potential breakthrough
Drummond,
> a client (for example an XDI RDF client) needs to
be able to tell from an XRI parser that they are not the same
identifier.
I am trying to dig into specifics. You are making a
case that the 2.0 abstract syntax fails to satisfy certain use cases, but
statements such as those above do little shed light onto what use cases
fail.
Why does the XDI RDF client need to be
able to distinguish between @cordance+west and
@cordance*(+west)?
~ Steve
From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Wednesday, May 02, 2007 9:23 PM To: 'Steven Churchill'; xri@lists.oasis-open.org Subject: RE: [xri] Potential breakthrough Steve,
The list of XRIs I gave
as examples in my email all happened to “normalize” to different XRIs. But as
soon as you normalize two different XRIs to the same XRI, then the client of a
parser can’t tell the difference between the two original XRIs.
An example would be
@cordance+west and @cordance*(+west). My email explained that these are
different identifiers expressing different contexts for the identifier “west”,
and thus a client (for example an XDI RDF client) needs to be able to tell from
an XRI parser that they are not the same identifier. If the parser normalizes
either one into the other, the difference in the context information is
lost. I hope that is clearer.
This will probably be easier to talk about on the call
tomorrow. =Drummond
From: Steven
Churchill [mailto:steven.churchill@xdi.org] 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] 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] 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] 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] 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]