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: Minutes: XDI TC Telecon Friday 2013-03-15

XDI TC Minutes

Following is the agenda for the unofficial telecon of the XDI TC at:
Date:  Friday, 15 March 2013 USA
Time:  09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)


Les Chasen
Animesh Chowdhury
Joseph Boyle
Phil Windley
Drummond Reed
Markus Sabadello


Peter Davis



Markus has come up with a use case and analysis for a second serialization parameter, which also suggests why we need a new name for the first one.
Markus gave us a walk-through of the presentation he uploaded about inner graphs. It explains that there are two ways of addressing/serializing the statements in inner graphs, and proposes a new boolean parameter, “inner”, for controlling this.
Because inner roots also produce a new set of implied statements, Markus also suggests renaming the “contexts” parameter to “implied”, as this way a single parameter would control whether all implied statements (representing all arcs that are present in the serialized graph but not part of the required statements) are included or not.
There was a consensus this made sense, and Markus should finalize this into a proposal. Drummond thanked Markus for the very clear and cogent explanation and diagrams.


We discussed the official spec drafting process and agreed on the high-level goal of having drafts of the first three specs—XDI Graph Model, Serialization, and Discovery—ready for the next Internet Identity Workshop that begins May 7.
Drummond explained the three basic options:
  1. Manual
  2. XHTML via Github
  3. DITA via Github (as originally proposed by Bill Barnhill)
Markus prefers #2. Animesh prefers #1. Joseph and Drummond prefers either #1 or #2, whichever would end out being simplest.
After a short discussion, we agreed that we should consult OASIS staff about the options before making a final decision.
# DRUMMOND to contact Chet at OASIS to arrange a short call on this topic.


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


This has been the subject of much work over the past week.


Drummond began by explaining the new "single delimiter level proposal" that has been developed. This grew out of last week's discussion about a dedicated UUID syntax, which grew into discussions about the role of delimiters in the ABNF.

We realized the longstanding assumption that we needed a "global" and "local" level of identifiers -- and thus different combinations of global and local delimiters to express different semantics -- was actually causing more complexity and confusion than it solved (as anyone who has tried to memorize our current multiplicity syntax knows).

So we had a simple idea: what if we eliminated the two levels of delimiters and just went down to a single level in which each delimiter had exactly one semantic meaning and none are overloaded with multiple meanings in different contexts?

This would require, of course, introducing a few new delimiters -- four, to be precise (to represent the four multiplicity options besides entity singletons, which are the default and require no special syntax).

Once we worked out what those four delimiters could be (as shown in the comment labelled “Drummond Reed 2013-03-13” on https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion), the result is simpler and more regular than the double-delimiter+cross-reference rules we currently have in the ABNF. Every subsegment/subgraph in an XDI address is either:

  1. delimiter + literal string
  2. delimiter + cross-reference (which repeats the pattern)

After this overview of the proposal, Phil’s reaction was that he loved getting rid of overloading of the elements, but that if it could get even simpler, that woudl be even better. Animesh said he said that it feels intuitive, especially the ampersand and colon.
We then discussed the email feedback from Bill Barnhill, who was not able to attend today’s call. 


Although we could not figure out how Bill’s proposal would meet all the multiplicity requirements, it does look significantly simpler. That became the starting point for a discussion around how we could simplify the syntax further.

Joseph felt in particular that we might be able to develop more intuitive syntax around multiplicity. He asked how important it was to stay constrained to use delimiters allowed by URI syntax. Phil seconded that question, suggesting that we might be able to develop a more simplified multiplicity syntax if we could use a larger delimiter set.

Drummond explained that XDI forms a bridge between two fields: structured languages on one side and Web addressability on the other. XDI graphs are structured data, but every node is intended to be XDI addressable using URI/IRI compatable syntax (potentially under multiple schemes). So both expressivity and addressability matter, and we’ve been working for years to find the best tradeoff.

Joseph pointed out that most platforms include URL-encoding libraries that make it relatively easy to convert strings to valid URIs or URI queries and back. So we agreed that all of us would take the action item to explore whether we could come up with significant simplifications to the syntax by using a larger delimiter set.

# ALL - send suggestions on this topic to the mailing list or post to https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion.

Joseph then there may also be more developer-friendly version of our JSON serialization, i.e., one that would make it easier to write _javascript_ code against, for example. He took the following action item:

# JOSEPH - make a proposal around a more developer-friendly JSON serialization.

Lastly, Joseph also suggested that, in the XDI Graph Model spec, we should publish the ABNF in several modules that provide different levels of validation of XDI grammar. Potentially this breaks down into:
  1. Segment-based parsing - fastest but provides least validation
  2. Literal validation
  3. Multiplicity validation

# JOSEPH to develop a proposal for this, starting with the segment-based ABNF.


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:



The next call is next week at the regular time.

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