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


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]