[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Potential breakthrough
Drummond,
I didn't switch places at all. The place where I've camped
all along is the same place I continue to camp. The context of every XRI
subsegment must be unambiguously clear, and your newest idea muddies the waters
more than ever, as illustrated by the following fictional
story:
Here are pictures of two objects: 1) /\/\/\/\ (a mountain
range) and 2) oVo (an owl).
A Boeing project requires fully-qualified
identifiers for mountains, and Boeing has assigned "@boeing*123"
to /\/\/\/\. The Boeing managed XRDS service points for /\/\/\/\ deal
mostly with GPS coordinates and elevations (so Boeing-built planes won't crash
into mountains).
An Ootao project requires fully-qualified identifiers for
owls, and the naming convention they follow includes a reference to the
manufacturer of the radio transmitter attached to an owl's leg. The transmitter
on oVo was manufactured by The Boeing Company, and oVo got the 123rd
Boeing-built transmitter that Ootao has put onto an owl's leg. So Ootao's fully
qualified identifier for oVo is "@ootao@boeing*123".
The Ootao project tracks various habitats for owls, and
Ootao is interested in /\/\/\/\ because lots of owls live there. Ootao's is
interested in the GPS coordinates, elevations, vegitation, prey, and weather
conditions in mountain ranges. Ootao brings "@boeing*123" into an Ootao context
as "@ootao@boeing*123" (so Ootao can include the Ootao-managed service points
dealing with vegitation, prey, and weather data in the XRDS).
BTW, oVo (known as "@ootao@boeing*123") doesn't live
anywhere near /\/\/\/\ (also known as "@ootao@boeing*123").
Marty.Schleiff@boeing.com;
CISSP From: Drummond Reed [mailto:drummond.reed@cordance.net] Sent: Wednesday, May 02, 2007 7:10 PM To: Schleiff, Marty; xri@lists.oasis-open.org 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]