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
