OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

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


Subject: Re: [xdi] Important issue about inner graphs, relational arcs, and notations


I understand this all conceptually but will need you or Markus to update the XDI syntax and examples in XDI Policy specification.

About the wikis - after our discussion on Friday's my intention had been to update the second and third wiki pages to point to the XDI Policy working draft and delete the contents. But I won't do that until a version of XDI policy is a browser-viewable working draft.

Dan


On Sun, Jun 8, 2014 at 3:41 PM, =Drummond Reed <drummond.reed@xdi.org> wrote:
On Sun, Jun 8, 2014 at 1:36 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
So if we decide this is a good thing, then the other question is when it would be practicable to implement it...

It is indeed the core question, as always on realizations like this. But for the XDI TC, the implementation question is one of specification, not code. The question of when to implement in code is one for XDI2, Respect Network, and other XDI development projects.

As far as the XDI TC specifications go, my answer is that, like the symbol shift and the contract shift, this "notation shift" is fundamental to multiple specifications, and in fact to the XDI graph model itself, since as we've been discussing on this thread, it reflects the ability for relational arcs to cross graphs.

So I think we don't have any choice but to incorporate it into the XDI Core, XDI Messaging and XDI Policy spec drafts. In other words, as we move forward Working Drafts of these specs, they should reflect this notation shift, and then the code bases implementing these drafts can make their own decisions about when to implement.

As a first step, as soon as there agreement about the notation shift, I think we should update the following wiki pages to bring them completely current, both with the contract shift and the notation shift:
And at the same time these pages should be updated to use the new ALLCAPSINBOLD convention for template variables in our documentation. More about that in a later message.

=Drummond 



On Sun, Jun 8, 2014 at 9:52 AM, =Drummond Reed <drummond.reed@xdi.org> wrote:
Markus: bingo! 

What's ironic about this is that you were the one that first convinced me (at a whiteboard in Andy Dale's living room) that we didn't need reification of full XDI statements because they could always be expressed using inner roots.

And now this is the logical result.

The convergence to a single notation is IMHO a huge win.

=Drummond (finally going to bed on a Saturday night ;-)


On Sun, Jun 8, 2014 at 12:33 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think handling inner roots like this would make some things a lot easier.
Animesh's concern about the duplication of inner roots on both sides of a statement would go away.
The confusion about having two notations would also go away.

I think the reason why we invented the short notation in the first place was to be able to write messages like this:
SENDER[$msg]!:uuid:1111$do/$set/(=a/#b/=c)

We really liked how the statement to be added was so clearly visible in the parentheses.

But the way you propose it now is actually not so bad either..
(SENDER[$msg]!:uuid:1111$do/$set)=a/#b/=c

Since you mentioned messages and link contracts, let me try to do the third case where we use inner roots: policies.

So I think what currently looks like this:
[=]!:uuid:1111/[=]!:uuid:1111/($do$if$and/$true/({$from}/$is/[=]!:uuid:1111))

Would then look like this:
([=]!:uuid:1111/[=]!:uuid:1111)($do$if$and/$true){$from}/$is/[=]!:uuid:1111

And ONLY like this, i.e. no other possible notation.

It seems like relational arcs staying within an inner graph would become a rare exception. Most of the time they would originate in an inner graph and cross into another.

Markus


On Sun, Jun 8, 2014 at 12:28 AM, =Drummond Reed <drummond.reed@xdi.org> wrote:
Markus' work on implementing link contracts using inner graphs has brought up a key issue related to inner graphs that I believe we must settles before we continue.

The issue is this: up until now we have said that XDI relational arcs can not cross graphs that have different root nodes, i.e., the subject and object nodes of a relational arc must always be within the same graph that has the same root node.

However in implementing link contracts using inner graphs, Markus discovered that it was necessary for a XDI message (under the common root node, or the "common graph") to reference a link contract defined in an inner root graph.

He and I discussed it last weekend, and then I though about it this week. My conclusion is that:
  1. Since 100% of XDI context nodes are uniquely addressable across all graphs (common, peer, inner), relational arcs MUST be able to cross graphs in any direction.
  2. We don't really have any choice about this, because if we restrict relational arcs to a single graph, we will end out with incorrect semantics for certain types of relational statements (one of them being the permission statements made by link contracts).
A fascinating result of this recommendation is that we would no longer have two notations ("normal" and "short form"). We would have only one. And in this one notation, you would never see two forward slashes inside parentheses, but one one. For example:

=a/#b/=c
(=a/#b)=c/#d/=e
=a/#b/(=c/#d)=e
(=a/#b)(=c/#d)=e/#f/=g
=a/#b/(=c/#d)(=e/#f)=e

There are two key places this would have a major effect: XDI messages and link contracts.

In XDI messages, a $set operation that needs to set a relational or literal statement would take this form:

(SENDER[$msg]!:uuid:1111$do/$set)=a/#b/=c                      <== for a relational statement
(SENDER[$msg]!:uuid:1111$do/$set)=a<#b>&/&/"value"    <== for a literal statement

In a link contract, permissions would also take the same form, i.e.:

(AA/RA)$do/$get/=b

Note that this would no longer require putting the object of the permission statement under the same inner graph. In fact, it MUST NOT require that, because that's the only way permissions can be specific. In other words, the following two permissions in a link contract would NOT be equivalent:

(AA/RA)$do/$get/=b
(AA/RA)$do/$get/(AA/RA)=b

The first statement provides $get permission to =b under the common graph. The second statement ONLY provides $get permission to =b under the inner root (AA/RA).

Interestingly, this would also solve the issue Animesh had on our TC call two weeks ago—a link contract can now point directly at any node it permissions. There is no need to duplicate nodes under inner roots just to permission them.

The fact that this would result in one notation is why I needed to raise this issue before we could resolve Markus' question below.

=Drummond  


On Fri, Jun 6, 2014 at 1:53 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think the following are all equivalent notations for the same graph:

1. ([=]!:uuid:1111/$public)($do/$get)=markus/$ref/([=]!:uuid:1111/$public)($do/$get)[=]!:uuid:1111

2. [=]!:uuid:1111/$public/($do/$get/(=markus/$ref/[=]!:uuid:1111))

3. ([=]!:uuid:1111/$public)$do/$get/(=markus/$ref/[=]!:uuid:1111))

4. [=]!:uuid:1111/$public/(($do/$get)=markus/$ref/($do/$get)[=]!:uuid:1111))

In 1. the first inner root is in normal notation, and the second inner root is in normal notation.
In 2. the first inner root is in short notation, and the second inner root is in short notation.
In 3. the first inner root is in normal notation, and the second inner root is in short notation.
In 4. the first inner root is in short notation, and the second inner root is in normal notation.

Markus








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