Re: [xdi] Special note about XDI syntax topic for tomorrow's XDI TC telecon

[Markus Sabadello <markus.sabadello@xdi.org>]

I just added a few more comments to the various open issues.

Markus

On Fri, Mar 22, 2013 at 5:53 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

I wanted to make sure that all TC members are taking the time to look closely at the 7 open issues with regard to the proposed XDI syntax revisions that will be the main focus of tomorrow's telecon.

To make it extra easy, I brought the OPEN ISSUES section of the new Context Functions page to YOU. It's copied in below, complete with illustrations (more examples are on the Context Functions page).

IF YOU ARE NOT ABLE TO MAKE THE CALL, please do weigh in here on the mailing list about your preferences with regard to each of these open issues (most of them are subjective "techaesthetic" judgements that are classic in standards work.)

Talk to you on the call,

=Drummond 

OPEN ISSUES

#1 Rules about Literals (Markus 2013-03-21)

1. Does everyone agree we can just use an empty predicate when the XDI object is a literal?

2. Does everyone agree that we should switch to using double quotes " " around literal data? Note that this means we can clearly distinguish between:

   1. Null - there is no literal node.
   2. Empty string - there is a literal node but the value is an empty pair of double quotes.
   3. Non-empty value - there is a literal node but and its value is enclosed in quotes.

#2 Member Collections (Drummond 2013-03-20)

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.

#3 Rules about Member Ordering (Markus 2013-03-21)

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.

#4 Rules About Member Ordering Context Symbol (Drummond 2013-03-21)

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:

1. [*2] (justified because this is the context symbol for reassignable identifiers)

2. [$2] (justified because this is in the XDI TC $ namespace)

#5 Rules about Member Types (Markus 2013-03-21)

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:

1. Collection is not typed, members are typed. Example: =example{+email}[<!1>] <-- attribute member =example{+printer}[!1] <-- entity member

2. Collection is typed, members are not typed. Example: =example{<+email>}[!1] <-- attribute member =example{+printer}[!1] <-- entity member

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

#6 Syntax for Variables (Drummond 2013-03-21)

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:

1. $( ) (this is the same syntax we had previously used for collections in the XDI Multiplicity proposal).

2. The following unused sets of bracket pairs:

   1. {( )}

   2. {[ ]}

   3. [{ }]

   4. <{ }>

   5. <[ ]>

#7 (Non-Normative) Syntax for Pattern Variables in the XDI 1.0 Specs (Drummond 2013-03-21)

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.

---