OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xdi] Exciting development: XDI graph model documented - please indicate your syntax preferences!

On Thu, Apr 11, 2013 at 9:50 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
1. If values now have JSON semantics, and XDI collections are now always ordered, why not allow specification of the two-line street address as a JSON array? The following looks like a legal statement even under current syntax.
   ["123 Main St","Apt 23"]

In the latest iteration of the model there's no such thing as collections, only classes, and they can have both ordered and unordered instances.

In general, the problem with your above XDI statement is that the two individual street lines do not have their own XDI addresses in the graph.

We could say that if a literal is a JSON array, then you could address its elements just like ordered XDI instances (e.g. =markus+address!4567+&street[1]), but that would be a pretty exceptional rule.

2. If retrieving =markus+address!4567+&street# can return a JSON array or object, or a JSON single value depending on whether you previously set it to an array / set one or more of its array members, vs setting it to simply a single value, then we don't need a singleton marker to specify singleton vs. collection; in fact it would simply lead to an error if mismatch.

I think I would argue for not allowing JSON arrays or objects as literal values, only strings, numbers, boolean.
3. Also, while [1] is very recognizable syntax for array indexing, if we only allow integer constant indexes and not computed expressions, we shouldn't have to use a paired delimiter, which should be reserved for cases where we need to specify the end of _expression_ that would otherwise be ambiguous. # is a nonpaired delimiter that would also be a recognizable choice to precede an integer index into a collection.

I could imagine using a nonpaired delimiter

4. I still do not get why the entity vs. attribute distinction is needed and especially why it has to be explicitly specified in every XDI address.

 For dictionary purposes, but I'd defer to Drummond for giving a more elaborate answer to this question :)


On Apr 11, 2013, at 10:39 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

Thanks Markus. By "symbol order", do you mean the order in which symbols appear when we document them?

Everyone else on the TC: please follow Markus' example and indicate your preference by posting to the wiki. (If you don't want to bother with the wiki, just copy the example set of XDI statements below, do a search-and-replace with your own preference for syntax characters, then send it back as a reply to the list and one of us will post it to the wiki).

If everyone can do this by tomorrow's TC telecon (9AM PT), we will make this our primary decision to close on. This is important since we have only 3 weeks left until the Internet Identity Workshop at which we want to do a plethora of XDI demos.

Here's the example model (reflecting Markus' syntax preferences):

Attribute symbol: &
Singleton symbol: |
Literal symbol: #

Order: ( "="/"@"/"+"/"$"/"!"/"*" ) [ "|" ] [ "&" ]

   "123 Main St"
   "Apt 23"

On Thu, Apr 11, 2013 at 5:02 AM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Just added my preference, and also fixed a few typos, e.g. in your preference you had


But it should be


In my preference, in addition to a different symbol for attributes, I also have a different order for the symbols.


On Thu, Apr 11, 2013 at 11:35 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
Major development this week. As we discussed on last Friday's TC call, all of our deliberations about syntax simplification (and the feedback we received from developers last week) made us realize we needed to fully document the underlying model the syntax was representing (and not the other way around, which is what sometimes has happened in our syntax discussions).

So Markus and I have done that. It's now on the TC wiki:

PLEASE REVIEW THIS and see if you can spot any flaws in the model (after all, it only represents 9 years worth of development work ;-)

What this model helped both of us realize is the following:
  1. While bracketing syntaxes like < > can be attractive for readability, they actually make it harder to parse the JSON and to define clean matching rules for variables. So it places a premium on using single character symbols vs. brackets.
  2. With a fully documented model of the semantics required, the choices about which syntax character to use to express which semantics becomes arbitrary. Any unique symbol will work.
So we have started a second wiki page exclusively for the purpose of letting TC member experiment with their own preferred choices for syntax symbols:


...is to copy the example block of XDI statements there into your favorite word processor and then start doing a search & replace of the syntax symbols to decide which ones you believe are most readable. Then, when you decide on your preference, just paste the final result back into the wiki page so others can see it.

If everyone does this sometime tomorrow (it should only take you a few minutes), then on Friday's TC call we can discuss it and drive this to a consensus.

REMEMBER: THE CHOICES ARE COMPLETELY ARBITRARY and based solely on TC members subjective judgements about readability. YOUR OPINION MATTERS.

So please do weigh in.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]