[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-11-08
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 08 November 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Markus Sabadello
Phil Windley
Drummond Reed
Dan Blum
Joseph Boyle
Animesh Chowdhury
None scheduled.
Joseph and Drummond did a major chunk of work this week on the ABNF, leading to the discussion below. They also worked on the Design Goals text, which Drummond plans to have finished before Thanksgiving.
Joseph and Drummond went over a key question about the ABNF for XDI Core. Following is the simplified _expression_ of an XDI path that Joseph developed:
xdi-path = ( *peer-root *inner-root *entity-node *attribute-node [ attribute-value ] ) / outer-root
attribute-value = ( attribute-singleton / ( attribute-collection [ attribute-member ] ) ) value
Joseph explained that this pattern is very simple and regular, but it has one drawback: it allows for all elements to be missing, and thus for an XDI path to be blank, which is currently not allowed. However to capture this rule would massively complicate the ABNF.
So the proposal Joseph is making is that we keep the ABNF simple by technically allowing a blank path, but in the spec state a separate normative requirement that the path not be blank.
Currently: “Paths are interpreted as absolute; that is, they start at the outer root. The initial outer root is not written, except in the special case of the empty path, which is written () instead of as an empty string. This special case is not described in the ABNF as it is not context-free, but is to be implemented in serialization after generation, and deserialization before parsing.”
Joseph said he favors using empty-string / null to be the outer root. He asked for the reasons not to do that. Drummond listed:
Empty/null statement components (i.e., subject, predicate, or object) are not allowed in RDF.
If we correspondingly change the contextual predicate from () to empty string, we would need another way to express supercontext, which currently is expressed using $is() statements, which would become simply $is.
Dealing with non-existent statement components can be difficult to deal with in code.
Drummond said this is “the number zero” problem, i.e., representing something that is nothing.
We ran out of time to fully close on this, so we will consider it, take it to the list, and put it on the agenda for next week’s call.
In the meantime, Joseph will plow ahead with a simplified ABNF that allows for an empty path.
We will discuss a question Markus has about contextualizing attributes.
I want to express that the person =markus has a certain associated icon (for display in a dashboard or other similar app).
Easy.
=markus<+icon>&/&/"....."
Now I want to say that =markus has a black/white (monochrome) icon (for display on certain limited devices).
Also easy.
=markus+monochrome<+icon>&/&/”.....”
Now I want to say =markus has an e-mail address.
=markus<+email>&/&/”.....”
And now I want to have an icon for my e-mail address attribute.
=markus<+email><+icon>&/&/”.....”
This works, it’s an attribute on an attribute, i.e. metadata, just like a timestamp or signature, etc.
But what if I want a black/white (monochrome) icon on my e-mail address attribute?
=markus<+email>+monochrome<+icon>&/&/”.....”
This is a violation of the XDI graph model, since attributes cannot contain entities.
Drummond’s reply:
Since an attribute can only contain an attribute, I see no choice but to contextualize the <+icon> attribute with <+monochrome>:
=markus<+email><+monochrome><+icon>&/&/”.....”
I don’t have any heartburn about this, since I think the rule can be:
Contextualize with entities until you reach an attribute.
Contextualize with attributes from that point on.
As we discussed this, Drummond pointed out another option, which is that the <+email> attribute can also be treated as an entity for the purpose of this type of specialization.
What that would mean is that the <+icon> attribute would not have to be an attribute of the <+email> attribute, i.e.:
=markus<+email>&/&/”.....”
=markus+email<+icon>&/&/”.....”
=markus+email+monochrome<+icon>&/&/”.....”
Markus said the problem with this approach is that it does seem very clean because <+icon> really is an attribute of <+email>.
Drummond pointed out the option we have discussed and discarded before of allowing complex attributes, e.g.:
=markus<+email><+monochrome+icon>&/&/”.....”
This would introduce an entirely different type of complexity—we don’t want to go there.
Another option that avoids that complexity is to use a cross-reference.
=markus<+email><+(+monochrome+icon)>&/&/”.....”
None of us liked this either.
So we returned to the rule that attributes should specialize other attributes. But Drummond raised a question about this. Should it be:
=markus+first<+name>&/&/”.....”
=markus<+first><+name>&/&/”.....”
Drummond felt the first pattern above should be used because +first is not an attribute.
Markus said that his first choice would be to use the second pattern above because the rule would be always using attributes to specialize attributes.
Joseph pointed out that an XDI attribute corresponds to a relational column name, where as an XDI entity corresponds to a subset of rows within a table, i.e., it could be the whole table, or a set of rows, or just one row.
We did not reach a conclusion and agreed we must further consider this. We will put it on the agenda for next week’s call; in the meantime please send any thoughts to the list.
None scheduled.
The decision queue stack is shown on the following three auto-generated Category pages:
https://wiki.oasis-open.org/xdi/CategoryLastCall
https://wiki.oasis-open.org/xdi/CategoryCurrent
https://wiki.oasis-open.org/xdi/CategoryHighPriority
See also this list of proposals that need to be developed:
https://wiki.oasis-open.org/xdi/XdiPendingIssues
The next call is next week at the regular time. (Note that Drummond may not be able to attend due to a trip to London.)
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 01 November 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Dan Blum
Markus Sabadello
Animesh Chowdhury
Joseph Boyle
Drummond Reed
Phil Windley
Andy Dale
We recapped what we learned at Internet Identity Workshop in Mountain View.
Drummond said that it made all the difference to show examples of how XDI actually works to solve a problem, because putting it in a specific problem context makes it much easier to understand.
Markus said that he is more convinced than ever of the need for higher-level tools and libraries to make it simpler for developers to adopt XDI.
Drummond explained that his workload leading up to IIW meant that he simply could not finish his sections of XDI Core, despite the availability of Joseph’s sections.
Joseph said that he had made progress on his sections, and is now largely waiting on Drummond.
Markus reiterated that he has not been able to put time into Messaging spec due to all the work preparing to demonstrate link contract initiation for IIW.
Drummond concluded that as always it comes down to resource availability and allocation. He plans to work with Respect Network VP Development Andy Dale, who he invited to the call, to discuss how Respect Network might be able to provide more resources.
The solution to clarifying the relationship of inner roots to entity or attribute contexts was to define inner roots as “dependent graphs” of the associated XDI graph nodes. So an operation on any particular XDI node also affects all of its dependent graphs.
Markus gave a demonstration of how he implemented this in XDI2. He said that this does make the persistence mechanisms more complicated because a $del operation must walk the tree of subcontexts to find all dependent graphs.
To illustrate this, Markus gave this minimal example of an XDI statement based on an inner root:
Normal notation:
(=a/+b)=c/+d/(=a/+b)=e
Short notation:
=a/+b/(=c/+d/=e)
Example operation on a context containing an inner root:
../$get/=a
Complete set of result statements of operation:
()/()/=a
()/()/(=a/+b)
=a/+b/(=a/+b)
(=a/+b)/()/=c
(=a/+b)/()/=e
(=a/+b)=c/+d/(=a/+b)=e
As a result of this analysis of inner roots, Drummond explained that we no longer need the concept of “statement roots”. We only need 3 types of root nodes:
The outer root: empty parens, i.e., ()
Peer roots: an XDI subject in parens, e.g., (=markus)
Inner roots: an XDI subject and predicate in parens, e.g., (=markus/+friend)
Joseph pointed out that inner roots have an analogy to RDF blank nodes in that they are not addressable with simple paths but require other statements. However, unlike RDF, they are in XDI fully and uniquely addressable.
We then discussed this further by looking at diagrams prepared by Markus.
Drummond asked for feedback on a term to use to describe the relationship between the four “levels” or “layers” or “spaces” of context node types:
Roots
Entities
Attributes
Values
He and Markus gave this example of an XDI address containing all 4 types of context nodes:
<-- ROOT --><-- ENTITY --><-- ATTRIBUTE --><-- VALUE -->
(=markus)
[=]!:uuid:1111$public
<$key>
&
Joseph said he recommended against adding another new term to describe these four types of contexts. Markus pointed out that in his opinion it is more important to stress how much they have in common—that they are all context nodes—than their differences.
Drummond said he would think hard about it because while he agrees strongly about how much these four types of context nodes share by being context nodes, he also believes their differences are critically important, and important in a different way than the distinction between singletons and collections/members, or the distinctions between different types of root nodes (outer, peer, inner).
None scheduled.
The decision queue stack is shown on the following three auto-generated Category pages:
https://wiki.oasis-open.org/xdi/CategoryLastCall
https://wiki.oasis-open.org/xdi/CategoryCurrent
https://wiki.oasis-open.org/xdi/CategoryHighPriority
See also this list of proposals that need to be developed:
https://wiki.oasis-open.org/xdi/XdiPendingIssues
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]