[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Special note about XDI syntax topic for tomorrow's XDI TC telecon
Does everyone agree that we should switch to using double quotes " " around literal data? Note that this means we can clearly distinguish between:
Should we support having collections of collections, i.e., should a third type of member context be a collection context?
Markus 2013-03-20: Yes, I think collections of collections are needed.
I am not sure I like the proposed ordering pattern using [1], [2], etc. without $ref arcs. How would one re-arrange the order, or insert or delete a member? With $ref arcs, that is more flexible.
Drummond 2013-03-21: It is a good question. Phil proposed this pattern, and I think he had it in mind for a collection of data (such as an array) that may just be written once and then only read after that. However, to clarify, the way the proposal is written up, it is not required, even if you use using the [1], [2] syntax, that these statements must be for the literals. They can be reference links to the permanent IDs in the collection. So it leads to two options:
Option A:
A1: =example{<+email>}[1]//"example-1@example.com" A2: =example{<+email>}[2]//"example-2@example.net" A3: =example{<+email>}[3]//"example-3@example.org"
Option B:
B1: =example{<+email>}[!1]//"example-1@example.com" B2: =example{<+email>}[!2]//"example-2@example.net" B3: =example{<+email>}[!3]//"example-3@example.org" B4: =example{<+email>}[1]/$ref/=example{<+email>}[!2] B5: =example{<+email>}[2]/$ref/=example{<+email>}[!3] B6: =example{<+email>}[3]/$ref/=example{<+email>}[!1]
In option A, the attribute ordering statements contain the actual literals. In option B, the ordering statements #4 - #6 are use to order statements #1-#3 that contain the actual literals.
An orthogonal decision is the actual syntax of ordered members. A concern I have is that the difference between [!2] as a persistent member ID and [2] as an ordered member number will not be clear enough. One possible solution for this is for ordered member numbers to use an explicit context symbol such as:
[*2] (justified because this is the context symbol for reassignable identifiers)
[$2] (justified because this is in the XDI TC $ namespace)
With the proposed member patterns, it's not possible to determine if something is an attribute or an entity by just looking at the member subsegment (subgraph). E.g. to find out if [!37] is an attribute or entity, one would have to look at the collection syntax, to see if it is {+printer} or {<+email>}. While this works, I am wondering if it would be better to be able to determine this directly from the member subsegment (subgraph).
Drummond 2013-03-21: I share the same concern. As we discussed today, there are three options:
Collection is not typed, members are typed. Example: =example{+email}[<!1>] <-- attribute member =example{+printer}[!1] <-- entity member
Collection is typed, members are not typed. Example: =example{<+email>}[!1] <-- attribute member =example{+printer}[!1] <-- entity member
Collection is typed, members are typed. Example: =example{<+email>}[<!1>] <-- attribute member =example{+printer}[!1] <-- entity member
Of these, the one I believe we should avoid is #1 (which ironically was the syntax we adopted with the XDI Multiplicity proposal because we were trying to simplify it). I am torn between #2 and #3.
We also need to decide on the new syntax for variables. The previous proposal, ($), now exclusively defines a root context (and in fact did before -- we just never caught that in the ABNF). Options:
$( ) (this is the same syntax we had previously used for collections in the XDI Multiplicity proposal).
{( )}
{[ ]}
[{ }]
<{ }>
<[ ]>
Another minor but still important consequence of incorporating all the available bracket syntax for XDI context functions is that we need to adopt a new syntax for when we want to indicate variables in XDI pattern specifications, such as the XDI message pattern.
One suggestion is to simply use XDI variable syntax (above) if the option we choose looks like it will work.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]