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-12-20


XDI TC Minutes


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


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


ATTENDING

Markus Sabadello
Drummond Reed
Joseph Boyle
Phil Windley

AGENDA

NEWS & UPDATES


None scheduled.

PRESENTATIONS/DISCUSSIONS

Authority-Relative Link Contracts

Markus and Drummond said that they had reviewed updates to the link contract patterns to ensure that link contracts are authority-relative. These updates are now shown at:


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


We discussed link contract terminology and agreed to use the term “authority” in place of “party”.


# DRUMMOND to update the terminology on the wiki page.


# DRUMMOND OR MARKUS: Update the examples at the end of the page.


Next Steps on Working Drafts

We briefly discussed the additions/corrections we want to make to produce XDI Core 1.0 Working Draft 02, including:


One open issue is that we need to review the list of predicates.


# JOSEPH AND DRUMMOND AND MARKUS: Do a draft of the Predicate Grammar section.


# DRUMMOND AND JOSEPH: Review spec for additional sections and compose issues list on the TC wiki.

Static Semantic Rules

Joseph cited the following in an email to the list:


https://mail.mozilla.org/pipermail/es-discuss/2013-December/035126.html


He explains:


This provides the term "static semantic rule" to describe non-ABNF rules such as:


The first does restrict the set of syntactically valid XDI statements, even though it is called a semantic rule. The second does not reduce the set of all valid XDI statements, or could be viewed as increasing it from a more basic smaller set not allowing triples in parentheses as objects.


The mail gives ignoring insignificant whitespace as another example of a static semantic rule, which could alternatively be implemented using syntax diagrams ("racetrack diagrams", which are equivalent to BNF). In the XDI case we have never attempted to add it to the ABNF, but have always had it as a static semantic rule external to the ABNF.


We agreed that this same approach can apply to rules we define in XDI Core 1.0.


“Membership” Statements

Drummond ran across the question: what’s the best way to express membership of one entity in another entity (such as an individual being a member of an organization) in the XDI graph model?


He proposed the following two options to discuss on the call:

OPTION 1: +member relational statements

Note that the following examples use shortened UUIDs for readablity.


1A   [=]!:uuid:1/$is+member/[@]!:uuid:2


1B   [@]!:uuid:2/+member/[=]!:uuid:1


Note that 1B could also be represented as an inner graph:


   ([@]!:uuid:2/+member)[=]!:uuid:1


OPTION #2: Contextual statements


2A   [=]!:uuid:1/$is()/[@]!:uuid:2


2B   [@]!:uuid:2//[=]!:uuid:1


This second approach uses XDI contextual statement with the implication that a subcontext is a "member" of a supercontext. That results in a new XDI address:


   [@]!:uuid:2[=]!:uuid:1


Markus said he would recommend the first one since it has a clean semantics that is not overloaded with other potential meanings.


Drummond then asked how  to best model a membership number, i.e., an attribute of a membership relationship. As we discussed that challenge, we added a third option:


OPTION #3: Collection/Member statements


3A   [@]!:uuid:2[+member]#0/$is/[=]!:uuid:1


This option reflects the use of our standard collection/member pattern to enumerate ordered members of a “+member” collection.


In this discussion, we realized that no single one of these patterns captures all the necessary semantics. In fact it takes a combination of several of them to do that. However this combination provides precises semantics for most typical queries about membership and membership numbers. We wrote up the following combination of patterns that make it possible to query the membership graph data in various ways:


   IS 1111 A MEMBER OF 9999 ?

   WHAT IS THE LIST OF MEMBERS OF 9999 ?


     [=]!:uuid:1111/$is+member/[@]!:uuid:9999

     [@]!:uuid:9999/+member/[=]!:uuid:1111


   WHAT IS 1111's MEMBER NUMBER ?


     [@]!:uuid:9999/+member/([=]!:uuid:1111<+member>&/&/0)


     ([@]!:uuid:9999/+member)[=]!:uuid:1111<+member>&/&/0


   WHO IS THE MEMBER WITH MEMBER NUMBER 0 ?


     [@]!:uuid:9999[+member]#0/$is/[=]!:uuid:1111


As a final note, we realized that we’ve never needed to diagram nested inner graphs, i.e., inner graphs that nest to more than one level. Drummond suggested that this would best be done by consecutive inner root nodes, i.e., drawing the diagram to correspond to this version of the XDI address:

     (@a/+member)(@b/+member)=c<+member>&/&/0


DECISION POINTS FOR THIS CALL

None scheduled.


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

We will take a break for the holidays. Our next call with be Friday January 3 at the regular time (9AM PT).




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