XDI TC Agenda

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.”

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

Spec comments by Hubert

Hubert has submitted a number of XDI spec issues to the OASIS issue tracker system:

https://issues.oasis-open.org/browse/XDI/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel

NEXT CALL

The next call is next week at the regular time.

xdi message

XDI TC Agenda

AGENDA

NEWS & UPDATES

PRESENTATIONS/DISCUSSIONS

Report from XDI editors subcommittee

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

https://github.com/OASIS-XDI-Technical-Committee/xdi-spec-docbook

Read-only / Append-only

NEXT CALL