Re: [xdi] Proposal for syntax for "terminal statements" to address XDI literal nodes

[Markus Sabadello <markus.sabadello@xdi.org>]

Two reasons why I think it's problematic..

#1 Intuitively, the parentheses are very much associated with contexts. () is the local root. () is used as a predicate in contextual statements. With your proposal, you would use () to address the only kind of node in the graph that's not a context.

#2 A more concrete, technical reason is again the argument that the graph that contains this feature would be problematic.

If you do 

=markus$($msg)$(!1)$do/$get+$b()/=drummond$!(+email)()

then this message would look like [see attachment].

In other words, in the message you now have a CONTEXT NODE (not a literal) with the address =drummond$!(+email)(). This is a contradiction.

-----

I might have another idea on how to do it: Use a similar pattern as with inner roots.

E.g. in your example, the address of your literal would be:

(=drummond$!(+email)/!)

This obviously can't be an inner root, because ! is not a valid relational arc.

So in a message, I would do the following:

=markus$($msg)$(!1)$do/$get+$b()/(=drummond$!(+email)/!)

What do you think? :)

Markus

On Sat, Feb 23, 2013 at 5:56 AM, Drummond Reed <drummond@connect.me> wrote:

On today's TC call, per the minutes I just sent out, it was suggested that it would be very useful to have an explicit XDI address for literal nodes -- not just for the attribute singleton that is the XDI context for the literal node, but the literal node itself.

Such an address would make it possible to query an XDI graph to find out whether a particular literal was null or not (because we have specified that if a literal is null, it does NOT have a literal arc, but if it's not null, it does have a literal arc).

On the call, we discussed that ending an XDI address in a bang would be an obvious choice for such a "terminal". So to request only the literal value of my default email address, you would use:

....$do/$get/=drummond$!(=email)!

When I went to review the ABNF about this, I realized that there is a problem with using a bang - or any other of our delimiters -- as the terminal character. The problem is that our ABNF allows all of our context symbol delimiters to be used standalone -- and we have several examples of where we need to do this. So to make any of our regular delimiters into a "terminal" where they cannot contain any further XDI subcontexts -- because a literal node cannot have a subgraph -- is problematic. It would require contortions in the ABNF.

So the next obvious choice was to use another IRI delimiter that we are not currently using -- such as a colon, which we decided to exclude from the xdi-char set.

However, in considering that option, I realized that we already have an ideal delimiter for use as a terminal. It's the only one that cannot have a subgraph: the empty parens "()". The Full Graph ABNF does not allow an empty paren to be used anywhere but as the absolute root of an XDI graph (where it appears only logically because it is not included at the start of any XDI context statements except absolute root statements).

So I posted to the ABNF discussion page (https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion) a proposal to add a rule to the ABNF that allows empty parens to be used as the terminal delimiter. Under this proposal, to get only the literal value of my default email address, you would use:

....$do/$get/=drummond$!(=email)()

The address =drummond$!(=email)() cannot contain any subcontexts. It is truly a "terminal" because it is the address of the literal node -- of which there can be only one at the address =drummond$!(=email).

To see whether the value of a XDI literal is null, you would just request a boolean literal:

....$do/$get+$b()/=drummond$!(=email)()

A result of $true would tell you the literal is not null, a result of $false would tell you that either the attribute is null or that it does not exist. If you don't know the latter, then you would have to do two $get statements:

....$do/$get+$b()/=drummond$!(=email)

....$do/$get+$b()/=drummond$!(=email)()

If the result of the first one is $true and the second is $false, then the value is null.

Thoughts?

=Drummond 

Attachment: graph1.png
Description: PNG image