[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2014-07-18
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 18 July 2014 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
Dan Blum
Drummond Reed
Joseph Boyle
Hubert Le Van Gong
Les Chasen
Eno Jackson
Phil Windley
Ning Zhang
Markus Sabadello
Reports from Respect Network launches and XDI hackathons in San Francisco and Sydney:
http://piratepad.nl/rn-hackathon-sf
http://piratepad.nl/rn-hackathon-sydney
These are two etherpad notes from the hackathons held in those two locations. Each had about 10 attendees. In both cases they group tackled actual XDI programming efforts. In Sydney this included looking at how to use the XDI2 _javascript_ library to set up a small _javascript_ server, not just the current Java server. They also played with setting up a NodeJS server.
The Sydney group also tackled setting up bi-directional link contracts and made some good progress. The etherpad notes are all the documentation was produced. Markus noted that all of this link contract work was “pre-notation shift” so it all needs to be adjusted for the notation shift.
Overall, there was a high level of interest and a very large number of questions, as was to be expected. This highlighted as always our need to continue to produce more documentation as quickly as possible. Markus also wants to make the XDI2 codebase and tutorials more complete and accessible.
Drummond and Markus didn’t have anything further to report as they have been tied up on the Respect Network World Tour.
Dan reported that he’s continued to work on the Policy Spec draft but needs input from Drummond and Markus. Drummond acknowledged that Dan had sent him some specific questions but he had not had time to answer them yet. He agreed with Dan that the editors (Dan, Drummond, Markus) need to have a dedicated breakout meeting to go over it. Drummond said he will not likely to be able to do that until he returns from Switzerland in another week, but it is a very high priority to schedule it. When that happens, a note will be sent to the TC list so that anyone may attend.
Dan also noted that the XDI signatures work was at the same stage—it needs one dedicated breakout session to push it over the hump.
Hubert said that reviewing the Core spec and the Messaging spec have a number of JIRA tickets that need attending to. Drummond agreed that this is a third area where we likely need one or more breakout sessions to push through them.
In a message thread within Respect Network, the question has come up whether certain parts of a graph can be “read-only”. For example, Matthew Sutton writes:
“Medical records and legal records, for example, would require the ability of a doctor or lawyer to write a bit of data, a medical record for example, but no one can ever change that field in the future.”
Dan Blum adds:
“XDI also needs an APPEND operation for similar reasons (e.g. append to audit trail without having write access)”
See here for the thread:
https://lists.oasis-open.org/archives/xdi/201407/msg00035.html
Some thoughts by Markus:
- The $set operation allows both creation of new data and modification of existing data. Previously we had the two separate operations $add and $mod for these purposes, but decided to merge them into one.
- If a sub-graph is only covered by a $get link contract, then it is effectively “read-only”. This protection would change if the link contract changes.
- For stronger protection, implementation-specific features could be used to prevent write operations on a lower level, e.g. XDI2 has a component called ReadOnlyInterceptor
- We could create some new $ word for this purpose, e.g. $readonly
Joseph: Doesn’t this require separate create and update permissions, not necessarily separate operation names? For logging, collections should have an append operation autoincrementing a pointer to next unused index. This is a standard RDBMS feature we’ve discussed before.
Animesh: Doesn’t the user have permission to do anything with their own data?
Dan: APPEND would be for an application operating with limited privilege in the user’s graph. I think it would be simpler and clearer to have a $APPEND operation that could be referenced specifically in link contracts. Its semantics would be that it doesn’t require $GET or $SET or $DELETE access. When an XDI service receives an $APPEND operation it should transparently add to the end of a collection (or create a collection) depending on the data structure affected.
Animesh explains the logic for replacing $add and $mod with $set: since statements in a message are not ordered , if there is $add and $del of the same context node in the same message, then there is a possibility that $add and $del will not be executed in the expecte order ($del before $add).
Also, for the client to know if a context node needs to be added or modified , a client needs to do a $get first. With $set , the $get is not needed.
Animesh and Peter discuss schema-ful vs. schema-less viewpoints.
Animesh noted that the structure (singleton or multi-valued) can be enforced by dictionary.
One can create as many relational arcs of course on top of the structure of the graph.
Peter asked how would one let the client know what the address is for a member in a collection if the client cannot specify what the address is.
Animesh suggested that there are two ways to let a client know the address of a particular node in a graph -
1. In the message response where the client has asked for a node, the server can respond with the address it has created (or if it already existed)
2. Create an entry in the requestor’s graph with the address of the node. This can be done via a governor link contract mechanism like it is done in the RespectConnect flow.
Drummond:
“At first blush I can see the case for being able to make branches of the graph write-once read-only. I'm wonder whether we could get that not be re-introducing $add and $mod in addition to $set, but by specializing $set to include $set$once.”
Notes from the TC call:
Markus’ suggestion was to reintroduce $add and $mod. Drummond agreed but noted that $add and $mod were replaced with $set in order to remove a server scalability issue with needing to do $mod checks, so reintroducing them reintroduces this issue.
Automatic singleton/collection conversion
Peter described a situation where one would have an attribute singleton in the graph, e.g. <#email>, and then later decide that a collection [<#email>] would be needed to add additional attributes.
Dan, Joseph:Would automatic conversion (if any) be allowed even on singletons that are meant to have a uniqueness constraint? Should at least be able to disallow it.
Joseph: I think singletons were originally meant to be single-valued by constraint, and that if you have potentially multi-valued data, it should be set up as a collection in the first place.
Peter: Don’t agree, automatic conversion makes sense to me. I view XDI data as freeform, not a fixed schema
See here for the thread:
https://lists.oasis-open.org/archives/xdi/201407/msg00029.html
Notes from the TC call:
Drummond noted that having some kind of server helper function could be useful for auto-generating collections, but this should not change the basic definitions of singletons and collections in XDI Core. The question of how this helper function should be exposed at the protocol level is still an open issue.
Hebrew support
XDI should support Hebrew (and in general all Unicode scripts/languages). Let’s discuss what is needed
- in the XDI graph model and serializations and ABNF
- in registries and discovery
Joseph: BiDi should be only in the front end display layer. The logical text model is still a sequence of character codes and a backend protocol like XDI should not be aware of it. XDI clients with a front end displaying text to the user would normally call platforms’ text display libraries which take care of it. BiDi display is prone to text jumping to the left or right and it’s possible in some cases the client will have to send directionality character codes to the display APIs; if problems come up the front-end developer will solve them then.
Would like feedback from Emmet on what current behavior is.
The XDI2 Converter tool is able to parse and convert the following XDI data:
=אריה<#email>&/&/"test@test.com"
=markus/#friend/=אריה
Spec Comments by Hubert
Hubert has submitted a number of XDI spec issues to the OASIS issue tracker system:
Issue XDI-25:
We discussed about different understandings of terms such as “endpoint”, “peer-to-peer”, and “authority”.
XDI signatures
Continue to discuss Peter’s updated XDI signature proposal:
https://lists.oasis-open.org/archives/xdi/201405/msg00030.html
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]