Minutes: XDI TC Telecon Friday 2013-04-26

[Drummond Reed <drummond.reed@xdi.org>]

XDI TC Minutes

Following are the minutes of the unofficial telecon of the XDI TC at:

Date:  Friday, 26 April 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)

ATTENDING

Animesh Chowdhury

Drummond Reed

Markus Sabadello

Les Chasen

Joseph Boyle

REGRETS

Phil Windley

NEWS & UPDATES

UPDATES TO XDI TC WIKI PAGES

Drummond has updated roughly a dozen of the wiki pages with the new syntax, and also started archiving pages that are now outdated. You can view progress at:

 https://wiki.oasis-open.org/xdi/RecentChanges

# DRUMMOND to aggregate examples on the ExampleXdiSyntax page.

PRIORITIES FOR VRM + PERSONAL CLOUD DAY MONDAY MAY 6

This Internet Identity Workshop pre-meeting day will include a personal cloud developer intensive where we will be talking lots of XDI. Those of us attending (which is almost everyone currently active on the TC) will be ready to show a number of XDI-related demos, including syntax, serialization forms, XDI discovery, and XDI dictionary construction.

PRESENTATIONS/DISCUSSIONS

ABNF

We’re not at a decision point yet but Joseph and Drummond gave an update on progress on the revised ABNF:

https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion (see the 2013-04-18 comment)

Their goal is to have a fully updated proposal by the next call.

REGISTERIES, CLASSES, SINGLETONS

Markus asked about the “I am” statement for registries, for example, what would the = registry call itself -- should it be a class or an instance? In other words, should the statement be:

1. ()/$is$ref/=

2. ()/$is$ref/[=]

Our decision was that it should be #1 -- an instance.

# DRUMMOND to confirm that the ABNF allows for = "" @ by themselves as instances.

DECISION POINTS FOR THIS CALL

This week's decision queue is the following set of proposals:

JSON SERIALIZATION OPTIONS

Now that syntax revisions are done and the ABNF is in progress, the next major decision point is serialization. There have been four recent developments in this area.

First, on 2013-04-06 Joseph proposed a new type of JSON serialization based on a statement parse tree format:

  https://wiki.oasis-open.org/xdi/JSONSerializationRules/Discussion (see Joseph Boyle 2013-04-06)

Second, this inspired Drummond to propose a type of JSON serialization based on a representation of the XDI graph tree:

  https://wiki.oasis-open.org/xdi/GraphTreeSerialization

Third, Drummond updated the XDI Display Format proposal to bring it current with the revised XDI syntax and also broke it into two variations:

1. Single-line display format (strictly one line per XDI statement, no nesting).

2. Double-line display format (one line for each unique subject/predicate pair, a second indented line for each object of that pair, nesting for inner graphs).

  https://wiki.oasis-open.org/xdi/XdiDisplayFormat

Fourth, Joseph has compiled an analysis of these different formats to help guide us in deciding which serialization formats it makes sense to pursue.

   https://wiki.oasis-open.org/xdi/JSONSerializationRules/Discussion (see Joseph Boyle 2013-04-25)

DISCUSSION

Drummond asked whether there should be a MIME type parameter about which display format to request. It was agreed that there should be, but no decision was made yet.

TERMINOLOGY

We discussed the term “context function” for the bracketed syntax. “context modifier” and “context type” were also suggested, but “context function” was the preference.

When referring to the collection of all context symbols and context function symbols, the term “syntax symbols” was suggested.

CLOUDSTORE MAPPING

Markus showed how he developed a mapping to the Cloudstore cloud data storage. This is documented at:

 https://github.com/projectdanube/xdi2-zephyr/wiki/Data-Mapping

This is not intended to be another serialization format option, but a mapping of the serialization needed to write an XDI graph to a particular data storage API.

DISCUSSION ABOUT SERIALIZATION OPTIONS

We talked about how to proceed with the two display formats and three JSON serialization formats discussed above. We agreed to the following steps:

1. Drummond will rename the current JSON format to SubjectPredicateSerialization.

2. Joseph will create a wiki page for the Parse Tree format.

3. One of us will update the SerializationFormats page to reference all the others.

We agreed on the following preliminary names for the three JSON formats. The decision on which ones will be part of the spec, and which ones will be mandatory for XDI clients and servers, will be made later.

Long Name	Short Name	Current Wiki Page
"JSON S/P flat statement serialization"	XDI/JSON/FLAT	https://wiki.oasis-open.org/xdi/JSONSerializationRules
"JSON parsed statement serialization"	XDI/JSON/PARSE	https://wiki.oasis-open.org/xdi/JSONSerializationRules/Discussion (See Joseph Boyle 2013-04-06)
"JSON context tree serialization"	XDI/JSON/TREE	https://wiki.oasis-open.org/xdi/GraphTreeSerialization

We agreed they should share a single MIME type (application/xdi+json), with a parameter to indicate the exact format. We also concluded that when parsing any of them, they are distinct enough from one another for an XDI processor to unambiguously identify the format. Potential names for the MIME type parameter are pattern, structure, type, representation, layout, form, format.

For example, the following MIME types could be used:

XDI/JSON/FLAT --> application/xdi+json;form=flat
XDI/JSON/PARSE --> application/xdi+json;form=parse
XDI/JSON/TREE --> application/xdi+json;form=tree

DECISION POINT QUEUE REVIEW

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

NEXT CALL

The next call is next week at the regular time.