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

[Joseph Boyle <planetwork@josephboyle.net>]

Thanks, Markus. Looking at this example from the Github page, it looks like it already does not require a separate call to create a & context value node.

ContextNode root = graph.getRootContextNode();
ContextNode markus = root.setContextNode(XDIArc.create("=markus"));
ContextNode animesh = root.setContextNode(XDIArc.create("=animesh"));
ContextNode name = markus.setContextNode(XDIArc.create("#name"));
Relation relation = markus.setRelation(XDIAddress.create("<#friend>"), animesh);
Literal literal = name.setLiteral("Markus Sabadello");

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:

1. Change XDI2 server code to accept literal statements of the form /&/
2. Ask client software authors to start accepting literal statements of the form /&/ .
3. Change XDI2 server code to generate literal statements in the form /&/ instead of &/&/ 
4. Client software authors start generating literal statements in the form  if they haven’t already in step 2.
5. 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.