Re: [xdi] Proposal: Eliminate value context node, keep literal node

Subject: Re: [xdi] Proposal: Eliminate value context node, keep literal node

I'd like to continue mailing list discussion of this proposal during this week so we advance it as far as we can before Friday's TC call. The reason is that Joseph and I want to conclude this issue before we do the next draft of XDI Core, as it affects both terminology and diagrams in that spec.

It is a fairly simple proposal that hasn't drawn much reaction yet so let me just pose 3 simple questions:

#1: Are there any TC members that either don't understand the proposal or disagree with it?

#2: Are there any remaining open issues with it (i.e., something Joseph missed)?

#3: If we approve this proposal and eliminate value nodes, we need to make a simple aesthetic decision about the visual graph notation: what shape should literal nodes take? There are two obvious options:

Open squares, as literal nodes are now.
Open diamonds, which is what value nodes were before, but which are no longer needed.

To get discussion going on this third question, here's my vote: open diamonds. My rationale:

With the elimination of value nodes, we would have just four shapes: open circles (roots), closed circles (entities), closed diamonds (attributes), and open diamonds (literal values). I like the simple parallelism of two shapes, being used both open and closed.
Closed diamonds (attributes) would be paired visually with open diamonds (the literal values of those attributes).
Both "ends" of the graph—the starting (root) nodes and the terminal (literal) nodes—would be open shapes, and both "middles" (entities and attributes) would be closed shapes.

That's my argument. Reactions?

=Drummond

On Sep 19, 2014, at 9:05 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I agree with Drummond, this is very clear, and I also look forward to discussing it on the TC.

In terms of transitioning the XDI2 code, I would probably vote for a radical, breaking change rather than a gradual transition.
I think the internal implementation of the graph model would have to change a bit to reflect the eliminated value context node:
https://github.com/projectdanube/xdi2/wiki/Implementation-of-the-XDI-graph-model

Markus
On Fri, Sep 19, 2014 at 4:52 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
Summary

I’ve always been bothered by the double ampersand &/&/ in literal statements, and I think we now have good arguments that it is unnecessary, and that we could start allowing literal statements containing only /&/ and eventually phase out the longer form. This is a proposal for this change.

We were already agreed not to allow value nodes with no literal node attached. Eliminating the separate value node would automatically eliminate this possibility. It would also help de-clutter graphs.

Example

Consider the example from http://xdi2.projectdanube.org/XDIConverter?sample=1 which currently has this tree graph, with both the value node and literal node on the bottom line:
<Screen Shot 2014-09-19 at 6.44.37 AM.png>
Display serialization without implied statements:
=markus<#email>&/&/"markus.sabadello@gmail.com”
Display serialization with implied statements, where we have 3 statements each creating one of the (non-root) context nodes, then 1 statement creating a literal node:
//=markus
=markus//<#email>
=markus<#email>//&
=markus<#email>&/&/"markus.sabadello@gmail.com"
In JSON serialization with implied statements:
{
  "/": [
    "=markus"
  ],
  "=markus/": [
    "<#email>"
  ],
  "=markus<#email>/": [
    "&"
  ],
  "=markus<#email>&/&": "markus.sabadello@gmail.com"
}
The statement =markus<#email>//& by itself would create a value node with no literal node, something we don’t want to allow.

I propose we eliminate this statement, and eliminate the terms “value node” and “value arc”. Instead the literal arc would come directly from the attribute context node.

After the change:

The parts highlighted in red above are removed.
We have 2 contextual statements each creating a context node, then 1 literal statement creating a literal node:
//=markus
=markus//<#email>
=markus<#email>/&/"markus.sabadello@gmail.com"
The final statement is a literal statement, which now doesn’t have an additional ampersand at the end of the statement’s subject.

In JSON serialization with implied statements:
{
  "/": [
    "=markus"
  ],
  "=markus/": [
    "<#email>"
  ],
  "=markus<#email>/&": "markus.sabadello@gmail.com"
}
Graphing would have the literal arc (green dotted line) come directly from the context node <#email>, and carry the label &. (Currently, it is unlabeled.)
After the literal node is created, the address =markus<#email>& would still be valid to refer to the literal node, if we need to refer to the literal node in later statements, even though it did not appear as such without the slash, in the literal statement that created the literal node. This means the & is not a contextual arc leading to a context node, but I think this is fine, and similar to the situation for relational statements, or for inner roots. There is no reason it has to be a context node, and in fact this introduces the unwanted possibility of a value node without a literal node.
Effects on other examples:

I checked the stock examples that come with http://xdi2.projectdanube.org/XDIConverter. Most statements containing ampersands are simply literal statements using &/&/ which would straightforwardly change to /&/ . One exception is in http://xdi2.projectdanube.org/XDILocalMessenger?category=5&sample=1 :

([=]!2222[$msg]!1$do$if/$true)[=]!1111<#age>&/$greater/{$msg}<#oldage>&

The part with ampersands is actually a conditional _expression_. Prior to the notation shift, it was actually enclosed in parentheses, and was in a more familiar form for a conditional _expression_ comparing two values, where each ampersand indicates we are retrieving the value:

[=]!2222[$msg]!1$do$if/$true/([=]!1111<#age>&/$greater/{$msg}<#oldage>&)

I think the post-notation shift is less transparent, but that is a separate issue to consider, and it would not affect the change proposed here.

Transition plan:

A gradual transition could work like this:

Change XDI2 server code to accept literal statements of the form /&/
Ask client software authors to start accepting literal statements of the form /&/ .
Change XDI2 server code to generate literal statements in the form /&/ instead of &/&/
Client software authors start generating literal statements in the form if they haven’t already in step 2.
Eventually, stop accepting literal statements of the form &/&/

Alternatively, we can simply bump the version number, specify that the new version has the change, and allow customers to upgrade both their version of the server code, and their own client code, simultaneously.

xdi message