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] On symbol ordering (was: [xdi] Exciting development: XDI graph model documented - please indicate your syntax preferences!)

The decision what is considered "general" and what is "special" is arbitrary too.

In your model, using the example of |&+email, the general-to-special ordering is singleton > attribute > unreserved.
This ordering is defined by your GraphModelStructure table.

But guess what, I just magically reshuffled your table:

And now suddenly the general-to-special ordering is unreserved > singleton > attribute, resulting in +|&email.

You can basically reshuffle the table any way you want to reflect a certain ordering of the symbols.
The leafs stay the same, only the hierarchy of the different node types is changed.
Arguments around specialization and recognition can be applied to all the possible orderings.

I don't necessarily like my ordering better than yours, only saying that it's an arbitrary choice.

Somehow this reminds me of the Spinning Dancer.


On Fri, Apr 12, 2013 at 9:04 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
Hey, I should just reinforce that my strong reaction was still just my personal reaction. In other words, with a solid graph model structure, we are down to a bedrock principle: as long as the mapping of the syntax to the model is unambiguous, then the choice of syntax (including ordering) is entirely subjective.

I just looked at the examples again and, if I stop and think about it hard enough, I can see the logic of special-to-general ordering. It looks very strange and foreign but then, I've been looking at $words and +words for a decade now. On this subject I'm the least objective person on planet earth ;-)

However here's a more objective perspective on this topic: I did an updated ABNF (see the 2013-04-11 comment on the ABNF Discussion page) to match the graph model structure. The rules for attributes, singletons, and definitions are very simple because the context symbols for each of these modifiers or "higher level contexts" are nested exactly the way they are in the graph model structure. 

To do the inverse (or any other ordering) would make for much more complex ABNF.

Just a perspective. I'm curious: what led you to consider reversing the order? Is there a reason it would be more intuitive from a programming perspective?


On Thu, Apr 11, 2013 at 4:23 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Funny, when I wrote my preference example, I had very similar ideas around specialization and about being able to recognize e.g. $words such such.

But somehow I ended up with a different conclusion.

Not sure why, I'll sleep over it.


On Fri, Apr 12, 2013 at 12:35 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
Thanks, now I understand -- I had never considered symbol order to be changeable because I've always thought of it in terms of nested contexts (similar to the graph model itself).

This is reflected in the structure of the table on https://wiki.oasis-open.org/xdi/GraphModelStructure. Each branch of the node type tree going left-to-right represents the parent context of the next branch, with the most specialized contexts being the leaf nodes.

So my assumption has always been that the order of the context symbols would follow the order of specialization in the model. For example, an unreserved attribute singleton would be:

   singleton > attribute > unreserved

If the symbol for singleton was | and attribute was & and unreserved was + and the instance was "email", this would be |&+email.

In theory I can see a case for the opposite rule, i.e., that the order should be from specific to general, which happens to be the order you would use in English, i.e.:

  unreserved > attribute >  singleton

...which would yield 


However what distresses me about that is that visually and mentally the core type is no longer "+email". This gets even more disturbing when you apply the logic to a $word like $uri. If you had an unreserved URI singleton with specific-to-general ordering, it would look like:


In short, a $word would no longer be recognizable as a $word.

I really don't like that. I highly recommend following the order of the model, so the most specialized context (e.g., $, +, =, @, *, !) always stays immediately adjacent to the identifier string.


On Thu, Apr 11, 2013 at 1:52 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Sometimes you have more than one symbol in a context, e.g. in your preference you have |>+email.

So there's the | singleton symbol, the > attribute symbol, and the + "main" context symbol.

What I meant by "symbol order" is that the order of these three symbols could also be arbitrarily defined by the TC, just like the symbols themselves.

I.e. we could do |>+email or >|+email or +|>email or +>|email or.any other combination..

In my preference I wrote that I'd prefer the "main" context symbol to go first, then the singleton symbol, and then the attribute symbol.


On Thu, Apr 11, 2013 at 7:39 PM, 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]