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:
- 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.
- 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/#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