[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XDI TC Notes Unofficial Telecon Monday 2016-03-21
Following are the notes of the unofficial telecon of the XDI TC held on:
Date: Monday, 21 March 2016 USA
Time: 10:00AM - 11:30AM Pacific Time (17:00-18:30 UTC)
The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken.
Markus Sabadello
Drummond Reed
Les Chasen
Kapil Vats
Phil Windley
Markus and Drummond have continued to work on the group messaging wiki page and added information and examples about link contracts and messages:
https://wiki.oasis-open.org/xdi/GroupMessaging
First, we reviewed the basics. We agreed on these two statements:
Group messaging always involves the group node.
Not all group nodes involve group messaging.
Markus then ran through the sections he added to the wiki page. He illustrated that the basic form of group messaging simply has a [$msg] context in the group context. It can be an immediate child context of the group, or it can be further specialized to add semantic filtering (see the next topic below).
Markus then covered how group membership works, and how individuals acting on behalf of the group is parallel to the way a set of devices can act on behalf of an individual.
We then talked about the differences between groups and channels. Drummond gave the following examples:
+!:uuid:x-1 is a group with no semantic meaning.
+!:uuid:x-1[$msg] is a context for group messaging with no semantic meaning.
+!:uuid:x-1#baseball[$msg] is a “channel” within a group with a specific semantic meaning.
Drummond pointed out that the concepts of channels or queues are both constructs for semantic filtering of messages and apply equally to all types of human messaging, not just group messaging. We agreed to break this out as a separate topic and TC wiki page (see the next topic below).
We then went into the topic of group administration. Markus asked the following set of questions using the example of the baseball “channel” for the group above:
Do you have to be a member of the group to subscribe to the baseball channel?
Do all members of the group receive the messages in the baseball channel by default, or do they have to opt-in?
More generally, what are the links or relationships between the channel and the group in terms of permissions and message flow?
We discussed that all of these cases exist in different group or “team” messaging products today—and that group link contracts can actually cover all of these cases. For example, they can:
Authorize the entire group to administer.
Authorize specific members of the group to administer.
Authorize a subgroup to administer.
Authorize a non-member (person or group) to administer.
Any combination of the above.
We concluded that it would be much better to keep all these concepts “atomic” and let link contract policies dictate what can and cannot be done.
We then discussed how a group link contract can reference members of the group. We agreed group link contracts should not need to re-enumerate the membership of the group. So we need an _expression_ that lets the link contract reference the members.
For a group’s publisher link contract, the policy can reference the group members as follows:
(+!:uuid:x-1/+!:uuid:x-1)$do/$add/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)($do$if$or/$true){$from}/$is/+!:uuid:x-1
(+!:uuid:x-1/+!:uuid:x-1)($do$if$or/$true)+!:uuid:x-1/$has/{$from}
+!:uuid:x-1/$has/=!:uuid:x-8
+!:uuid:x-1/$has/=!:uuid:x-9
+!:uuid:x-1/$has/=!:uuid:x-10
For a group’s subscriber link contract, this same pattern doesn’t work, since the subscribers of a push link contract are listed using $is() relations rather than being expressed in a policy:
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/=!:uuid:x-2
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/=!:uuid:x-3
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/=!:uuid:x-4
We then discussed if and how the $is() relation can reference the members of the group. The example Markus developed uses an inner graph as follows:
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/(+!:uuid:x-1/$has)
+!:uuid:x-1/$has/=!:uuid:x-2
+!:uuid:x-1/$has/=!:uuid:x-3
+!:uuid:x-1/$has/=!:uuid:x-4
The problem with the group member reference (in bold) is that it references an inner graph, which does not actually exist. This violates the rule about a relational arc and its reification in an inner graph being two separate and distinct components of an XDI graph.
We realized that the solution may be a relational variable: a variable whose target is not a single context node, but the set of context nodes that are the target of a relation. For example (see bold text):
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$is()/{+!:uuid:x-1/$has}
+!:uuid:x-1/$has/=!:uuid:x-2
+!:uuid:x-1/$has/=!:uuid:x-3
+!:uuid:x-1/$has/=!:uuid:x-4
A relational variable references all the context nodes that are the target of the relation, rather than an inner graph. We agreed this is potentially a very powerful construct that would have many uses in XDI—and which we would have to add to XDI Core 1.0 if we decide it is needed.
As an alternative, we also discussed an approach where the subscribers of a push link contract are also expressed in the link contract’s policy, rather than using a $is() relation, e.g. as follows:
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true){$from}/$is/+!:uuid:x-1
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and$or/$true){$to}/$is/=!:uuid:x-2
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and$or/$true){$to}/$is/=!:uuid:x-3
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and$or/$true){$to}/$is/=!:uuid:x-4
With this approach, the policy of the subscriber link contract can reference the group members as follows:
(+!:uuid:x-1/+!:uuid:x-1)$push$do/$push/+!:uuid:x-1[$msg]
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true){$from}/$is/+!:uuid:x-1
(+!:uuid:x-1/+!:uuid:x-1)($push$do$if$and/$true)+!:uuid:x-1/$has/{$to}
+!:uuid:x-1/$has/=!:uuid:x-2
+!:uuid:x-1/$has/=!:uuid:x-3
+!:uuid:x-1/$has/=!:uuid:x-4
# ACTION ITEM: Markus to update the GroupMessaging XDI TC wiki page with this new pattern.
We also discussed the different ways to semantically organize and filter messages using “channels”, “queues”, and “conversations” (also called “threads”).
The insights from this call were:
A “channel” is simply a class used to semantically organize a collection of messages (and thus may not need a dollar word at all). It is a one-dimensional organizational construct.
A “queue” and its member “threads” is a different and more advanced mechanism for organizing messages. It is a two-dimensional construct in which the first context (the “queue”) is used to establish the semantic context, i.e., a class of messages, and the second context (the “thread”) is used to establish an instance of that class, i.e., a specific conversational thread within that class of messages.
# ACTION ITEM: Drummond to write this up on a new XDI TC wiki page called SemanticFiltering.
Drummond suggested that on the next call, we review the writeups from Markus and Drummond on both of the topics above, and then move into the basic flows for group messaging, i.e. the next section of https://wiki.oasis-open.org/xdi/GroupMessaging.
# ACTION ITEM: Markus and Drummond to create a first draft proposal on the wiki page.
The next call will be the following week at the usual time (Monday 10AM PT). The link to where agenda items can be posted for the next meeting is: https://docs.google.com/document/d/19oDl0lbb56Grehx2a5flZnhrgnua5l8cVvC_dJ8fTXk/edit?usp=sharing
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]