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: RE: [External] [xdi] Minutes: XDI TC Telecon Friday 2013-03-15

Thanks for discussing the feedback at the meeting.  Unfortunately (well, from an XDI point of view) I'll be on a cruise ship during the next call, without internet or phone.  As a result I thought I'd send out some more thoughts in email.  

On meeting all the multiplicity requirements, could someone point me to the wiki page or or doc that lists those?  If so I'll see about sending an email that shows how my proposed syntax addresses them, or falls short.

I think IIW is a great target for a release date.  I'd recommend earlier for a releasable product though, which will allow socializing the spec docs with key people, and revising if needed, prior to IIW.  In other words I think IIW is a great target for a beta release, but not for an alpha one.

On the spec format, DITA is in my opinion the technical winner...but didn't get adopted in the TC so we need something people are more familiar with.  XHTML is a possibility, but I'd caution against using XHTML as HTML (in other words writing XHTML but publishing as a non-XHTML mime type).  That was a big trend when XHTML was on the rise, as a way of getting around the strictness of XHTML syntax, but it means the browser is basically just treating it as a flavor of HTML. I'd actually recommend MarkDown instead, for the following reasons: (1) Github supports MarkDown rendering out of the box if the file has the suffix MD; (2) Github supports MarkDown editing on the site now; (3) MarkDown, while inferior to DITA from a full-kit publishing perspective, still is an intermediate format that can be rendered to HTML5 or PDF, and probably does cover 80% or so of markup needs.  I do think using Github is a clear win.  

On "Drummond explained that XDI forms a bridge between two fields..."  I think Drummond is right, but I also think it is broader than that.  Let me digress a little about Semiotics.  From wikipedia, semiotics is "is the study of signs and sign processes (semiosis), indication, designation, likeness, analogymetaphorsymbolism, signification, and communication.".  Semiotics in digital systems and communities is my specialty.  The wikipedia article says further on, paraphrased, that... semiotics is often divided into three branches: (1) Semantics: Relation between signs and the things to which they refer; their denotata, or meaning; (2) Syntactics: Relations among signs in formal structure; (3) Pragmatics: Relation between signs and the effects they have on the entities who interact with them.  Up until now each Web technology has focused on one of those three.  URLs focus on syntactics. RDF focuses on semantics.  XACML focuses on pragmatics.  Granted, these are broad interpretations of the focus of these technologies, but I think it fits.  The revolutionary leap enabled by XRI addressing that both XDI and ADDIE take is the combined focus on all three branches of semiotics as they apply to the data web.  XDI will address synchronous use cases, ADDIE asynchronous.
Kind regards,
Bill Barnhill
Booz Allen Hamilton - Belcamp,MD
Cell: 1-443-924-0824
Desk: 1-443-861-9102

From: xdi@lists.oasis-open.org [xdi@lists.oasis-open.org] on behalf of Drummond Reed [drummond.reed@xdi.org]
Sent: Saturday, March 16, 2013 12:26 AM
Subject: [External] [xdi] 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]