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

["=Drummond Reed" <drummond.reed@xdi.org>]

William, you are correct that it's not the first time that a shift has happened that affects existing code bases. This would actually be the fourth shift this calendar year (the symbol shift, the link contract shift, the notation shift, and now this "value node shift").

Every time a "shift" is proposed, the situation is the same: the TC must decide whether the gain is better for the XDI standard as a whole vs. the pain that the change causes. And the pain isn't just limited to code bases; it also affects spec documents, tutorial documents, wiki pages, etc.

And the pain is felt by all of us. All implementers, all editors, all documenters.

For the previous three shifts this year were all carefully considered for these tradeoffs, and in each case there was a consensus that we should proceed with the shift. so we did not need to hold a vote.

The process for considering this fourth proposed shift, which would remove value nodes, is the same as what we used for all the others. The proposal is put before the TC, the whole group discusses it, and if we have consensus, we move forward. If we don't, we keep discussing it until we either reach consensus, drop the proposal, or hold a vote.

Although the value node shift is a change to the actual XDI graph model (vs. the other three shifts, which were changes in XDI syntax), Joseph outlined in his proposal a clear migration path for XDI implementations. I have discussed this with Markus with regard to the XDI2 implementation and he believes it is reasonable.

To reiterate a point I made earlier in the thread, this is not a decision that we would ever make lightly. This is in fact the second time that Joseph has had to push an issue hard, for six months or longer, in order to get us to look at a key piece of the graph model in a new way. I for one was extremely skeptical about this for the longest time. But, to his great credit, Joseph persisted because he saw how significantly it would simplify the graph model and thus the learning and implementation curve for developers everywhere. And with 10 years behind us on building this standard, we are definitely committed to building something that will last.

We will make this agenda item #1 on tomorrow's call, so we can discuss it further there.

=Drummond  

On Thu, Sep 25, 2014 at 11:06 AM, William Dyson <william@darmik.com> wrote:

So the proposal is to break existing code that we have invested large amounts of funds and resources in.

It is my understanding that this is not the first time that this large shift has happened and also not the first time that funds and resources have been lost.

William 

On September 23, 2014 at 7:41:42 PM, =Drummond Reed (drummond.reed@xdi.org) wrote:

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:

1. Open squares, as literal nodes are now.
2. 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:

1. 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.
2. Closed diamonds (attributes) would be paired visually with open diamonds (the literal values of those attributes).
3. 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:

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.