OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

Markus, good points. I thought about your "literal inner root" suggestion this afternoon but realized it has an issue similar to my proposal:
Then I realized there's a different approach that doesn't have either problem. 

This approach is not to try to turn a literal node into any kind of context -- because it's not a context! -- but instead just provide a clean way to reference a literal node in the XDI graph using an XDI statement. Here's what I put as part of a new comment on https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion.

literal                 = literal-value / literal-ref
literal-value           = literal-context "/!/" data-xref
literal-ref             = literal-context "/!/()"                                                              <== NEW
The  literal-ref rule defines a valid XDI statement is NOT the literal value, but a reference to the literal value. So if you want to ask for the literal value of the default email address for ="" you could use:
I'm proposing using () as the object of this statement instead of some other delimiter -- or a variable like ($) -- because:
  1. Although () stands for "context" throughout the ABNF, it also stands for "graph". And the literal value is indeed its own little graph (just not an XDI graph).
  2. By not using a variable like ($), we avoid the need for developers to worry about the variable uniqueness in a query if the query is just for multiple literal values. For instance, you could use the following to ask for only the values of three literals in your XDI graph:
Lastly, this literal node reference syntax still solves the problem I brought up in my email a week ago: it provides a means for unambiguously referencing a literal node even just for purposes of detecting its presence or absence. For example, if you wanted to check whether the $!(+email) attribute of =markus is null, you could use the following two queries:
If the response to the first one was $true and the second $false, you would know that =markus$!(+email) is present but it's current value is null.



On Sat, Mar 2, 2013 at 10:07 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
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 


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:


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

So in a message, I would do the following:


What do you think? :)


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:


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:


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:


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:


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]