[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Potential breakthrough
Marty, This is ironic. As you expected, my answer
to both would be @ootao@boeing*reputation. But whereas now I’m satisfied
that this *doesn’t* have any
problems, you now believe it does. How did we switch places so fast? ;-) I’ll explain why I believe it doesn’t,
and then you can explain why you believe it does. The reason I formerly believed that “@boeing*reputation”
needed to be “opaque”, i.e., recognizeable as a single identifier
by an XRI parser, was that it might be “misunderstood” when placed
in another context if it didn’t “stick together”. However
once I revisited that assumption, I realized that “@boeing*reputation”
asserts exactly three things: 1) The reassignable identifier “boeing”
is an a global organizational context (@). 2) The reassignable identifier “*reputation”
is in a local context (*). 3) The reassignable identifier “*reputation”
is in the context of the identifier @boeing. Now, when we place @boeing*reputation in
the context of @ootao to get @ootao@boeing*reputation, it tells us exactly five
things: 1) The reassignable identifier “ootao”
is an a global organizational context (@). 2) The reassignable identifier “boeing”
is an a global organizational context (@). 3) The reassignable identifier “*reputation”
is in a local context (*). 4) The identifier @boeing is in the
context of the identifier @ootao. 5) The identifier “*reputation”
is in the context of the identifier @boeing. This all seems very straightforward to me
now. By eliminating the “sticky star” rule, the interpretation of
the XRI “grammar” rules you have been asking me for just got a lot
easier. (I’m glad I hadn’t tried to write them yet, because I saved
myself a lot of time ;-) What am I missing? =Drummond From: Schleiff, Marty
[mailto:marty.schleiff@boeing.com] Hi Drummond (& All), I'm not sure I understand what you're
suggesting, so I'm seeking confirmation. 1) How do you propose to represent
"@boeing*reputation" in the context of "@ootao"? 2) How do you propose to represent
"*reputation" in the context of "@ootao@boeing"? If your answers to #1 and #2 are the same,
then we've still got problems. Marty.Schleiff@boeing.com; CISSP
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]