[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XDI TC Telecon Friday 2013-03-29
Following are the minutes of the unofficial telecon of the XDI TC at:
Date: Friday, 29 March 2013 USA
Time: 09:00AM - 10:30AM Pacific Time (16:00-17:30 UTC)
ATTENDING
Les Chasen
Joseph Boyle
Animesh Chowdhury
Markus Sabadello
Drummond Reed
Phil Windley
Drummond and Les gave a brief update that XDI.org is now actively proceeding with planning for the next generation of XDI infrastructure based on the progress we are making on the technical specs.
This week's decision queue is the following set of proposals:
Out of last week’s discussions, a new proposal has been developed based on the JSON data model:
https://wiki.oasis-open.org/xdi/JsonModel
This is to resolve open issues in the ABNF as covered on the following pages:
https://wiki.oasis-open.org/xdi/XdiAbnf
https://wiki.oasis-open.org/xdi/XdiAbnf/Discussion
https://wiki.oasis-open.org/xdi/ContextFunctions
We reviewed the following open issues:
#1: SHOULD ELEMENTS BE REQUIRED TO BE ORDERED?
Drummond made this revision yesterday to match the JSON data model. This means only member contexts are unordered. An example of what this looks would now look like for a set of 3 email address. In this example:
The first statement is for a “singleton” -- the default email address for ="">
The next 3 statements are an array of element contexts to order the collection
The final 3 statements are the 3 instances of email addresses, each identified with a UUID (note that UUIDs are not required - any unique !number will work)
=drummond+email<$string>/$ref/
=drummond+email!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001<$string>
=drummond+email[1]/$ref/
=drummond+email!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001
=drummond+email[2]/$ref/
=drummond+email!:uuid:9ce739f0-7665-11e2-bcfd-0800200c0002
=drummond+email[3]/$ref/
=drummond+email!:uuid:3a96e460-7be9-11e2-b92a-0800200c0003
=drummond+email!:uuid:f81d4fae-7dec-11d0-a765-00a0c91e0001<$string>/<>/
=drummond+email!:uuid:9ce739f0-7665-11e2-bcfd-0800200c0002<$string>/<>/
=drummond+email!:uuid:3a96e460-7be9-11e2-b92a-0800200c0003<$string>/<>/
We discussed the terminology around the fact that you can have both ordered and unordered instances. Markus developed the following example:
=markus+email[1]<$string>/<>/"a@gmail.com"
=markus+email[2]<$string>/<>/"b@gmail.com"
=markus+email[3]<$string>/<>/"c@gmail.com"
=markus+email!:uuid:1234<$string>/<>/"d@gmail.com"
Drummond pointed out that this has actually not changed from the previous ContextFunctions proposal. The only difference is that the ordered and unordered instances are no longer both in square brackets, i.e., what is now the element context. The element context is exclusively for ordered instances, and the unordered instances are now in the member context (which corresponds to the rules in JSON).
Drummond explained that the reason this is still semantically “clean” is that all instances in the member context are identified with !numbers. That is the function of the ! space.
Markus then pointed out an issue with how this approach would handle singletons. The pattern Drummond had recommended for singletons was the bold line below:
=markus+email!:uuid:1111<$string>/<>/"1@gmail.com"
=markus+email!:uuid:2222<$string>/<>/"2@gmail.com"
=markus+email!:uuid:3333<$string>/<>/"3@gmail.com"
=markus+email[1]/$ref/=markus+email!:uuid:3333
=markus+email[2]/$ref/=markus+email!:uuid:2222
=markus+email[3]/$ref/=markus+email!:uuid:1111
=markus+email<$string>/$ref/ =markus+email!:uuid:1111<$string>
There are three problems with this pattern:
A $ref can only be made from the =markus+email<$string> node, and not the =markus+email node, because the =markus+email node cannot have a $ref and also be the member context for the =markus+email[x] array.
Unlike the =markus+email!:uuid: member instances, or the =markus+email[x] array instances, the =markus+email singleton instance cannot be referenced without including the <$string> value context.
Lastly, the structure of versioning subgraphs becomes much harder with this approach to singletons, because to match the JSON object model (and keep things simple), the version subgraph must be a child of the parent member or element context and not the value context. This means the version subgraph for =markus+email would not just describe the versioning of the =markus+email<$string> literal, but would also describe the versioning of all changes to =markus+email. That would be different than the version subgraphs for all other instances of =markus+email, which would describe only the changes to one literal.
Our conclusion was that this singleton pattern would not work. Drummond explained that this was the one issue with the JSON model that he had stayed up late several nights this week “banging his head about” because it was the only issue holding back adoption of what is a dramatically easier syntax and set of graph model rules.
We played with several options until Markus pointed out that the solution was right there in the syntax we originally developed for XDI multiplicity. Rather than seeing the singleton as falling into EITHER the ordered array of instances or the unordered collection of instances, it is in neither. It needs to be independently and algorithimically addressable outside of either. And that’s what we developed to differentiate between singletons and collections in XDI multiplicity - a special syntax for singletons. Only now, as with everything else with the JSON model, it is signficantly simpler. Here is the same example as above shown with the proposed syntax (again with the singleton statement in bold):
=markus+email!:uuid:1111<$string>/<>/"1@gmail.com"
=markus+email!:uuid:2222<$string>/<>/"2@gmail.com"
=markus+email!:uuid:3333<$string>/<>/"3@gmail.com"
=markus+email[1]/$ref/=markus+email!:uuid:3333
=markus+email[2]/$ref/=markus+email!:uuid:2222
=markus+email[3]/$ref/=markus+email!:uuid:1111
=markus!(+email)/$ref/ =markus+email!:uuid:1111
The beauty of this solution is that it accomplishes the objective completely and solves each of the three issues above without breaking compatibility with the JSON data model or requiring new syntax for an additional context function.
As a result of this insight, we then had complete consensus on the following decision:
DECISION: Elements MUST be ordered and ordering will use only positive integers with no special syntax.
At this point Phil had to leave the call to catch a plane.
#2: ALLOW BOTH MUTABLE AND IMMUTABLE ORDERING? WITH WHAT PREFIX?
Mutable ordering uses unprefixed digits, e.g., [3], or a * prefix, e.g., [*3]. Immutable uses either a $ prefix, e.g., [$3], or a ! prefix, e.g., [!3].
On this topic, Phil said that the idea of an immutable array is very unusual - he can’t think of one.
Drummond explained that the primary use case for immutable ordering was version numbers in a version array.
Animesh asked what the use case is for a version number to be persistent -- will it affect the client? Drummond admitted that the persistence binding was controlled by the authority for the XDI graph, but explained that the reason for the persistence syntax was so that processors would be able to tell algorithmically that all subsegments of an XDI path were persistent. However in saying that, he realized that this could be specified as a requirement of the XDI $ dictionary definition for $v.
Joseph then suggested a different way to handle it, which is with a standard policy statement that would declare if array element values were mutable or not.
Markus had yet another idea, which is to define the use of !x (i.e., ! followed by an integer) as an ordered instance. So you could order ! instances when you needed persistent ordering.
Drummond agreed, and thought that using $x might also work for that. In any case, Drummond said that he was satisfied that we could live without persistent element IDs.
DECISION: No special syntax will be defined for immutable ordering of element contexts.
#3: SHOULD THE NATIVE JSON DATATYPES BE SPELLED OUT OR SINGLE LETTERS?
$object OR $o
$array OR $a
$string OR $s
$number OR $n
$boolean OR $b
$null (which may not actually be needed)
First Joseph asked why we need to include value contexts at all since the JSON serialization will carry the JSON datatype for any literal.
Drummond explained these reasons for including value contexts:
They indicate which XDI statements can identify literals (which solves the literal reference problem).
They include the type information in an XDI subject. This means in a serialized graph it is not necessary to inspect the object of an XDI statement to learn its type.
Value contexts can be specialized—the atomic types are only the base building blocks.
It allows multiple JSON data types in an array (and also in member instances), which matches the JSON data model.
There was a consensus that for all these reasons, value contexts are a required part of the JSON model.
Joseph then proposed that it would be good to allow an empty value set, indicated by empty chevrons “<>”, for the following reasons:
It would avoid bulk in XDI messages that do need the value context metadata, only to indicate the presence of an XDI literal.
To be able to express that the type is undefined.
There was a good discussion about it but no conclusion yet as to whether undefined value contexts should be added to the JSON model.
At this point Joseph had to leave the call.
We then discussed whether the native JSON data types should be spelled out or abbreviated. Even though both Markus and Drummond originally expected that they should be abbreviated, to save space, after experiencing the difference it makes in usabilty, they both agreed with Animesh that it is worth the average of 5 extra characters it in terms of XDI adoption to spell them out fully, at least for the XDI 1.0 specs.
TRIAL DECISION: The native data types will be spelled out as $words as they appear in section 2.1 of the JSON RFC (http://www.ietf.org/rfc/rfc4627.txt):
value = false / null / true / object / array / number / string
The exception is “true” and “false”, for which the value $word is $boolean.
**************
With those decisions made, Drummond noted that the TC had reached a very significant milestone: both a dramatic simplification of XDI syntax AND full alignment with JSON as widely deployed and proven graph model/data model for the serialization of data.
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
The next call is next week at the regular time.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]