XDI TC Agenda
Following is the agenda for the unofficial telecon of the XDI TC at:
Date: Friday, 08 March 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (17:00-18:30 UTC)
ATTENDING
Animesh Chowdhury
Joseph Boyle
Markus Sabadello
Drummond Reed
Phil Windley
AGENDA
NEWS & UPDATES
OASIS InterOp Demonstrations at RSA 2014
https://lists.oasis-open.org/archives/xdi/201303/msg00023.html
We discussed whether we want to participate in this event next February.
The consensus was that we would be ready and should participate.
#DRUMMOND to respond to Jane Harnad. (DONE)
PRESENTATIONS/DISCUSSIONS
DICTIONARY PATTERNS PROPOSAL STARTED
Drummond began work on the formal proposal:
We discussed that, once this page is done, we will have another “home page” for one of the 1.0 specs.
QUERIES
This led us to a discussion about XDI queries, because once Dictionaries is ready, it will be the only XDI 1.0 spec listed on https://wiki.oasis-open.org/xdi/XdiOneSpecs that does not have a “home page” with a complete proposal.
Markus explained a idea he had about how message policies relate to queries.
- An XDI endpoint processes a message policy before it executes the message to evaluate whether it should process the message.
- The same process could be applied at the “other end” of the process using a “query policy”.
- The query policy would filter the statements from the results of a $get message to reduce it to the matching statements.
- It could use variables in the same way as other policy expressions.
- It could also use boolean logic trees in the same way other policy expressions.
Animesh agreed: the results of a $get is a graph, and then policy _expression_ can be applied as a filter on that graph.
It also means the current work on create a policy _expression_ language could be the seeds of a query language.
The consensus was that we should proceed with drafting an XDI 1.0 query proposal based on this approach.
SPEC DOC DRAFTING PROCESS
Drummond explained the three basic options:
-
Using an automated process with Github and DITA and autoposting to Kavi.
-
Using manual process with Word or HTML document templates.
-
Using Github with the Word or HTML with autoposting to Kavi.
Markus pointed out that the DITA process that Bill set up treated every section of a spec as a different file. That may be more granular than we need. It may be enough to simply treat each spec as a file, since the specs are modular anyway.
We held a short discussion about who was interested in being an editor on which spec. Initial indications were as follows:
- XDI Version 1.0 Graph Model - Drummond
- XDI Version 1.0 Serialization - Joseph, Drummond
- XDI Version 1.0 API - Markus
- XDI Version 1.0 Dictionary - Drummond
- XDI Version 1.0 Discovery - Animesh
- XDI Version 1.0 Link Contracts - Animesh
- XDI Version 1.0 Queries - Joseph
DECISION POINTS FOR THIS CALL
This week's decision queue is the following set of proposals:
ABNF UPDATES (DRUMMOND, MARKUS, JOSEPH)
We continued discussion on the key items raised on the list over the past week.
First, Drummond offered a standing ovation to Joseph for solving the tail matching problem. It was a very elegant and effective solution.
Second, Markus showed his XDIParser utility:
http://xdi2.projectdanube.org/XDIParser
It is a very elegant implementation that shows XDI parsing using two different parsers (AParse and APG) with different outputs and statistics.
Thirdly, we discussed the remaining open issues:
- Closing on the literal-ref rule.
- Enhancing the visual graph notation to use open boxes for literal references and solid boxes for literal values.
- Serialization of the literal ref in JSON.
- Adding support for CR, LF, and CRLF for full graph statements.
- Whether support for UUID syntax should be built natively into XDI (the ABNF for this is shown in a comment at the top of the ABNF discussion page).
With regards to issue #1, there was a consensus that we should proceed with the literal-ref rule:
literal-ref = [ peer ] literal-context "/!/()"
Markus pointed out that it still does not make a literal node “addressable” in the same way as a context node. So you cannot have a relational arc to it. However you can refer to it in a link contract and an XDI query.
We discussed a specific example of how it would work in an XDI query. If the link contract said:
…$do/$get/(=markus$!(+email)/!/())
And the message requested:
A) …$do/$get/(=markus$!(+email)/!/()) ⇐ SUCCEED
B) …$do/$get/=markus$!(+email) ⇐ FAIL
Request B would fail because it asks for the literal context node, not the literal node value, and the link contract only give $get permission on the literal node value.
Drummond said this is important since metadata about the literal context node may be sensitive—for example the version history of the literal, which is a subgraph rooted on the literal context node, may not be private data.
Markus pointed out that what’s new about this is that a link contract would be referencing am entire statement in the target graph, not just an address in the target graph, which has been the norm so far. However we agreed this would be very useful. Markus showed an example of how it would work for providing access to a subset of relational arcs:
…$do/$get/(=markus/+friend/($))
With regard to issue #2, we agreed that we should add the open box/solid box notation to the visual graph rules, where open boxes (with dotted arcs) indicate literal references, and solid boxes indicate literal values.
With regard to issue #3, the JSON serialization of the literal ref, the consensus was to serialize the literal ref as an empty JSON array.
# DRUMMOND OR MARKUS - to update the JSON serialization spec. (DONE)
With regard to issue #4, after reviewing that CR, LF, and CRLF are all part of the ABNF base rules, it was agreed to use them as the separators for XDI statements in the Full Graph ABNF.
xdi-graph = xdi-statement *( ( CR / LF / CRLF ) xdi-statement )
With regard to issue #5, the UUID issue, Drummond took the time to explain this issue in some depth because it’s not so much a technical issue as an aesthetic and adoption choice by the TC.
He began by explaining that the official form of a UUID in IRI form is:
urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001
This is because a UUID is a registered URN namespace (the oft-used “uuid:” form is not an official URI scheme). Thus, if UUIDs will be used widely in XDI, this would mean using a cross-reference in the form:
!(urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001)
That turns the UUID into an immutable XDI address, or “i-number”.
The alternative, if UUIDs will be heavily used in XDI, is to build support directly into XDI immutable syntax. The proposed form is:
!:f81d4fae-7dec-11d0-a765-00a0c91e0001
!::f81d4fae-7dec-11d0-a765-00a0c91e0001
In other words, the colon delimiter would be used to create a subspace of immutables reserved for UUIDs.
Phil said that he’s okay with this approach but is worried about the overall complexity of XDI syntax, i.e., one advantage of the URI cross-reference approach is that the format will be more familiar to developers when they first see it.
Drummond agreed, but shared the following points:
- This is only an issue when a developer is using XDI (vs. some higher level language or interface that is doing the actual reading/writing of XDI).
- If the developer is using XDI directly, the developer is going to need to understand the other syntactic constructions of XDI, such as the cross-reference syntax and using ! for immutable addresses.
- If the developer is going to understand that, then having direct syntactic support for UUIDs is a tiny increment (and arguably easier than using cross-references).
- UUIDs are likely to play a very large role in XDI infrastructure (see the book Trillions, http://www.amazon.com/Trillions-Thriving-Emerging-Information-Ecology/dp/1118176073).
- Using the native colon syntax will save 10 characters and one nested cross-reference parsing step every time a UUID is used in an XDI address. That could actually start to be a significant advantage when XDI queries and posts are tunnelled through HTTP/S URIs.
But perhaps the most important point is deeper than all of these. Building “native” support for UUIDs into XDI syntax sends a signal to developers that UUIDs are architecturally part of XDI. Drummond pointed to the IETF doing the same thing when they drafted the URI spec (http://www.ietf.org/rfc/rfc3986.txt). They included native syntactic support for IPv4 and IPv6 addresses so that an Internet Protocol endpoint was a direct architectural component of any URI scheme that wanted to use it.
Doing the same thing for UUIDs in XDI would send the same message.
Markus observed, “It’s a simple matter of courage”. If XDI is going to become a broadly used semantic data interchange format and protocol, then this is the kind of feature it will need.
On this question we concluded that we would all consider it further over the weekend and continue discussion on the list next week.
DECISION POINT QUEUE REVIEW
The decision queue stack is shown on the following three auto-generated Category pages:
See also this list of proposals that need to be developed:
NEXT CALL
The next call is next week at the regular time.