Markus, I stand corrected. I should have called the & symbol a "virtual context node" because I agree there's no actual additional context node in the graph. The & is simply the address of a literal node expressed in an XDI address.
To answer your question, I drew it out the graph and, I agree, it consists of 7 nodes and 7 arcs.
NODES
common root node
entity singleton node =drummond
attribute singleton node <#email>
literal node ""
entity singleton node =markus
entity collection node [$msg]
entity singleton node *!:uuid:1234
ARCS
#1 to #2 label =drummond
#2 to #3 label <#email>
#3 to #4 label "&"
#1 to #5 label =markus
#5 to #6 label [$msg]
#6 to #7 label *!:uuid:1234
#7 to #4 label $get
Does this match your expectations?
In this case, do you see an issue with the virtual representation of a literal being able to be represented in the XDI graph?
=Drummond
The key is that the arc
On Fri, Oct 9, 2015 at 2:02 PM, Markus Sabadello <> wrote:
Still not sure. How would you draw this
statement?
=drummond<#email>/&/""
And then how would you draw this?
=markus[$msg]*!:uuid:1234/$get/=drummond<#email>&
Would you agree that if you have these two statements in a graph,
and you draw the graph, it would consist of 7 nodes and 7 arcs ?
Markus
On 10/09/2015 06:56 PM, =Drummond Reed wrote:
On Fri, Oct 9, 2015 at 2:55 AM,
Markus Sabadello <>
wrote:
Thanks I think this ABNF can work, but I have to
point out that there is a quite significant change to
how I had understood the XDI graph model so far.
This is the fact that with this ABNF, both the subject
and object of a relational arc may be literal nodes.
While we had definitely agreed that objects may be
literal nodes, for subjects this could be a problem.
1. Your XDI Core V1.0 WD05 in section 4.3 probably has
to be changed in any case:
"A Relational arc describes any other relationship
between two context nodes."
2. I believe literal nodes as subjects would seriously
impact our RDF compatibility, e.g. in section 4.3.3
you say:
"XDI relational arcs are the equivalent of RDF
properties that describe the relationship between
two RDF resources"
So I think this all hinges on the consideration of the
& context node. To be specific, I'm talking about the
node that has an XDI address that looks like this:
=drummond<#email>&
The final & at the end of that address represents
the one and only one literal node that can be present on
the attribute
=drummond<#email>
However I submit that the & node is not itself a
literal node (and in fact cannot be a literal node). It is
the special context node that can be used to represent the
literal node as a context.
Thus there is no change to the XDI graph model and the
only change I think is needed in the spec is to add text
to the Literal Arcs and Literal Statements section further
clarifying the answers to precisely the questions Markus
raised here.
Markus, if you agree, I will make those changes
in Working Draft 05 this weekend.
=Drummond
On 10/09/2015 08:27 AM, =Drummond Reed wrote:
As Joseph and Markus and I head
into the final 10 days of editing, I want to
make sure anyone who has not looked over the
ABNF does so ASAP.
https://wiki.oasis-open.org/xdi/XdiAbnf
The
two questions Markus raised on the last TC
call have been answered to his
satisfaction (I believe—correct me if I'm
wrong, Markus).
I
did my own proof-reading tonight and found
two small bugs that were an easy fix:
peer-root-variable
= "{" peer-root "}"
==> peer-root-variable
= "{" peer-root-instance "}"
inner-root-variable
= "{" inner-root "}"
==> inner-root-variable
= "{" inner-root-instance "}"
The one remaining question (that Joseph
had poised in the previous version of the
ABNF) is whether we should make any
adjustments to the whitespace rules in the
ABNF we inherit from JSON. My proposed
answer is "No" because:
I don't see any reason we should be more
restrictive than the ABNF rules that the
JSON community has already established.
We will (I assume) normalize out
whitespace for any XDI signature or
encryption operations anyway.
Does anyone disagree? If so, please speak
up now by reply to this thread so we can
eliminate this as a topic we need to talk
about on next Monday's call.
BTW, I strongly encourage everyone on
the TC to attend the next two calls (Monday
Oct 12 and Monday Oct 19, both 10-11:30PT) as
they are our final two calls before we open
the XDI Core 1.0 Committee Specification Draft
vote after the October 19 call. It will be an
online vote, so it will have to run for a
minimum of 1 week to close before IIW, which
is why we need to open it on the 19th.
Thanks,
=Drummond
