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


Marty,

 

I think I understand the point you are trying to make. However I believe there’s a logic flaw in this scenario. You first posit that Boeing assigns @boeing*123 as the identifier of a mountain. You then posit that since Ootao got a radio transmitter for an owl from Boeing, Ootao in its own context (@ootao) would give that radio transmitter the XRI “@boeing*123”, creating the composite XRI @ootao@boeing*123.

 

But why would Ootao do that when it knows that the identifier “@boeing*123” has been assigned to a mountain? While it’s entirely _possible_ for Ootao to decide it wants to assign the identifier Boeing uses for a mountain (@boeing*123) to an radio transmitter, Ootao would be asking for trouble doing that because everyone else who wants to understand the identifier @boeing*123 means could go to @boeing to ask what it means and find out it identifies a mountain.

 

Ironically, this ends out illustrating precisely the difference between using @boeing or *(@boeing). If ooTao wants to set up its namespace as you described, and assign Boeing-built radio transmitters numerical identifiers _without_ any chance of confusion with XRIs assigned in Boeing’s own namespace, Ootao could construct the algorithm:

 

            @ootao             *(@boeing)        *sequence-number-of-radio-transmitter

 

This would yield @ootao*(@boeing)*123. Now there’s no chance of confusion with @ootao@boeing*123.

 

=Drummond

 


From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
Sent: Thursday, May 03, 2007 1:24 AM
To: Drummond Reed; xri@lists.oasis-open.org
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
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

 

 


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]
Sent: Wednesday, May 02, 2007 12:08 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Potential breakthrough

 

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
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

 

 


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]