XDI TC Minutes
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 22 February 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (17:00-18:30 UTC)
ATTENDING
Giovanni Bartolomeo
Markus Sabadello
Drummond Reed
Joseph Boyle (final part of call)
GUESTS
Animesh Chowdhury
NEWS & UPDATES
Giovanni Bartolomeo
Giovanni joined the call with the news that due to other commitments he’ll be ending hsi activities in OASIS. He said that he’s sorry to be stepping down, but will continue to stay in touch with the work of the TC.
We thanked him for his contributions to XDI and agreed to continue to stay in touch.
PRESENTATIONS/DISCUSSIONS
XDI2 IMPLEMENTATION OF INNER GRAPHS AND VISUAL GRAPHING
Markus gave a demo of new functionality in the open source XDI2 project. He showed two publicly-available XDI utilities that have new functionality:
DECISION POINTS FOR THIS CALL
This week's decision queue is the following set of proposals:
ABNF UPDATES (DRUMMOND, MARKUS, JOSEPH)
Much discussion and progression has happened this week, all of it recorded on the Discussion page. It resulted in an updated “Full Graph Model ABNF” proposal now on the ABNF page:
We discussed the Full Graph Model ABNF. Drummond explained the two key advantages:
- It now includes all the constraints we have developed on the basic XDI contextual/relational/literal graph model.
- It provides clear semantic labels for all of these concepts, which will make it much easier to document in the XDI graph model specification.
In our review, Markus noticed that “member” should not be defined as an optional part of the “collection” rule, so that was fixed.
Markus noted that in his XDI2 implementation he is still using the segment-based ABNF. What he wants to do next is create a parser to check other instances of XDI documents to see how they meet the ABNF.
Joseph is working on a streamlined version of the Full Graph Model ABNF for parsing -- one that still reflects all the rules but is as fast as possible for parsing.
Later in the call we noted that there is a need to have a precise XDI address for a literal node. Our assumption that literal nodes are addressable using a query, e.g.:
…$do/$get/(=example$!(+email)/!/($))
...is flawed, because as Markus points out, the object of the literal statement in the query is not actually a literal.
So either we need to make an exception for this kind of statement, or we need to create a special rule for addressing a literal node. Those on the call agreed the latter was preferable.
The obvious rule would be to terminate the XDI address with a ! character representing a literal, e.g.:
…$do/$get/(=example$!(+email)!
The problem with this approach is that ! is a delimiter that otherwise can be used as a standalone subgraph identifier like all other global and local context symbols. So it would make the ABNF much more complex to isolate the use of ! as a terminal character only.
# DRUMMOND to post a proposal to https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion. (DONE)
EQUIVALENCE LINKS (DRUMMOND & MARKUS)
Although this is now in Last Call, a new related issue has come up: the need for multiple parameters controlling operations in an XDI message.
https://wiki.oasis-open.org/xdi/EquivalenceLinks
Drummond explained why multiple parameters were needed: an XDI client might need to request both:
- Deferencing of a response graph.
- Proxy discovery of a response graph.
Markus explained the formula that he suggests: XDI message context + operation context + parameter context would become the context for the parameter value.
Markus and Drummond both like $proxy as the name of a boolean parameter a client can use to request that an endpoint to serve as a proxy to perform XDI discovery as needed to complete an XDI $get request.
We talked about whether another parameter should be the type of return graph requested, e.g., whether the client wants just a boolean value returned. We have been expressing this as a subcontext of the $get operation, e.g.:
$get+$json$boolean!
Markus and Drummond felt that this “simple content negotiation” format was still desirable. We agreed there could be something more complex like HTTP content negotiation if needed, and this could be done with parameters.
Fiinally we discussed the format of parameter statements in XDI messages. We discussed three options, of which examples are shown below:
1. =markus$($msg)$(!1)$get$proxy/$only$boolean/$true
2. =markus$($msg)$(!1)$get$!($proxy)/!/(data:,true)
=markus$($msg)$(!1)$get$!($proxy)/$is+/$b
3. =markus$($msg)$(!1)$get$proxy$!($b)/!/(data:,true)
There was consensus that the first option was not preferable because it forced semantics that should be reserved for literals into relations.
However even though the second form avoids that problem by using a literal to represent the value of the $proxy parameter, it’s drawback is that according to our Literal Datatype Rules proposal (https://wiki.oasis-open.org/xdi/LiteralDatatypeRules), it requires a second statement to express that the datatype is a boolean. This additional weight to an XDI message is very undesirable (we want XDI messages to become lighter, not heavier).
Then we reviewed https://wiki.oasis-open.org/xdi/LiteralDatatypeRules and realized that we had left an exception for specific datatypes, i.e., those defined with $words. $t is the first example. So we realized that if we created a $word datatype for booleans, the extra statement could be eliminated because the attribute singleton would be self-describing.
We discussed it and agreed that booleans would be so common that we should use a single-letter $word and agreed on $b. We agreed the same approach should apply to JSON numbers using $n.
# DRUMMOND to add to https://wiki.oasis-open.org/xdi/Xdi%24Dictionary. (DONE)
We also discussed some examples of how XDI discovery across peers should work. We agreed that from a discovery standpoint, the following two requests would provide the same result:
=markus$($msg)$(!1)$do/$get+$b!/(=alice)(*joseph)=drummond$!(+email)
=markus$($msg)$(!1)$do/$get+$b!/(=alice*joseph)=drummond$!(+email)
Drummond explained it this way: everything in the “peer root graph” (in parentheses) is navigated first, like walking from tree to tree in the forest floor, before finding the target tree and climbing up the branches to reach the eggs in a bird nest (the data). So in proxy discovery, (=alice)(*joseph) would be equivalent to (=alice*joseph).
We agree that this all needs to be documented as part of the XDI Discovery spec.
Lastly, we discussed that we should review the XDI message pattern to see if all 5 message “header” or “envelope” statements are needed for the lightest-weight forms of XDI messaging.
DECISION POINT QUEUE REVIEW
The current queue is:
- Closure on the suggestion about having an address for a literal node in the ABNF.
- Formalize proposal for XDI message parameters (needed to finalize Equivalence Links and XDI Discovery).
- Formalize proposal for how proxy discovery works in XDI discovery.
- Approve proposal for Poicy _expression_.
- Return focus to formalizing the rest of XDI messaging.
NEXT CALL
The next call is next week at the regular time.