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


On Sat, Mar 2, 2013 at 10:55 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I think it would work, although it feels a bit strange to have literal statements whose objects are not literals.

In this particular type of literal reference statement, the object of the statement IS a literal mode -- it's just that the statement is a REFERENCE to the literal node, not the actual value. It's also an implied statement, i.e., as you say, it's just like a variable. More on this below.

Also, strictly speaking, in your $get operation you would request a statement that doesn't really exist in the target graph, and you still get something back.

If my graph is:

=markus$!(+email)/!/(data:,...)
=markus/+friend/=drummond

then in the following examples, all the requested statements (= arcs in the diagram) really exist in the target graph:

...$do/$get/(()/()/=markus)
...$do/$get/(=markus$!(+email)/!/(data:,...))
...$do/$get/(=markus/+friend/=drummond)

With ...$do/$get/(=markus$!(+email)/!/()), that statement doesn't exist in the target graph.

To be clear, the statement that is being referenced does exist in the graph. It's the literal arc from =markus$!(+email) to its literal node. But you're right, the statement =markus$!(+email)/!/() does not itself create a new arc in the graph.
 

But that might be okay I guess. Variables also work this way.

That's what I was going to say - it's just like a variable. In fact, it could be that it would be better to make it a variable, in which case the ABNF would simply make that variable legal, i.e., =markus$!(+email)/!/($) would be valid.
 

One challenge would be, how does this get serialized in XDI/JSON:

{
"=markus$!(+email)/!":["()"]
}

Here you can't tell if it's a "literal-value" or a "literal-ref".

I agree but I'm not sure if we need to. In other words, the use of this literal reference statement is for either:
  1. $get requests, where you want to get the value of a literal node and nothing else (i.e., you don't want the metadata that might exist at the literal context node).
  2. $del requests, where you just want to delete a literal node (and any value it contained) but NOT delete its parent literal context node.
We don't need it for $add or $mod requests, since for either of those you will always have a value.
 
I'm also wondering how to draw this in a diagram.

I think that it will only appear in an inner graph (e.g., a $get message), and in that graph, it would appear as a literal node (square box) without a value.
 

But let me play with this a bit and I'll see how it goes..

If it can be made to work somehow, maybe the syntax should be ../!/! rather than ../!/()  ?

I thought about that too. For some reason it doesn't seem right. I'd be tempted to make it a variable -- ($) -- first. But somehow it seems right to do a "real" variable to reference context nodes and an "empty variable" to reference a literal node.

But keep playing with it and see what you think.

=Drummond 
 



On Sun, Mar 3, 2013 at 3:56 AM, Drummond Reed <drummond@connect.me> wrote:
Markus, good points. I thought about your "literal inner root" suggestion this afternoon but realized it has an issue similar to my proposal:
  • My suggestion of =markus$!(+email)() introduced a new kind of context which is not really a context.
  • Your suggestion of (=markus$!(+email)/!) introduces a new kind of root that is not really a root.
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:
...$do/$get/(=markus$!(+email)/!/())        
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:
...$do/$get/(=markus$!(+email)/!/())
...$do/$get/(=markus$!(+tel)/!/())
...$do/$get/(=markus$!(+birthday)/!/())
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:
...$do/$get+$b!/=markus$!(+email)
...$do/$get+$b!/(=markus$!(+email)/!/())
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.

Thoughts?

=Drummond 








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 

=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 












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