Re: [xdi] Reconsideration of dictionary syntax

I think I understand Joseph's message.

The entity-attribute distinction is making an already complex syntax even more complex. Anything that would simplify the syntax could be a good thing.

But - Do we need the distinction to establish containment relationships, i.e. this <first> <name> attribute and this <work> <telephone number> is part of =dan's record in his personal cloud?

There are potentially many entities contained within entities visible in the graph (I want to propose examples but fear that I don't understand what an entire "data set" for some "application" would look like in XDI, i.e. would it be a bunch of linked graphs or one big graph with many levels of containment? I suspect it could either, anything one wants to try to express. What are we trying to enable? Anything?

In other words a long path of entities to get to my phone number. And entity potentially branching off with its own attributes. And potentially cross references branching across.

It seems you propose a choice of e-a relationship invisible to the human eye (in a dictionary) or inscrutable to the human eye (in a complex syntax)

Dan

On Tue, Nov 12, 2013 at 11:38 AM, Joseph Boyle <planetwork@josephboyle.net> wrote:

I think the pipe character is the next character to consider for additional bracketing. However, since it doesn't distinguish left and right, we should use it for the most finite class of expressions that need to be enclosed in a bracket syntax. Would this be variable instead of definition? By the way, Ruby syntax uses the pipe character to delimit the argument variables when starting a method definition, while many languages use curly brackets to enclose definition bodies.

I think it would be even better to eliminate the pervasive entity-attribute distinction marking and free up the angle brackets. No users have asked for this feature. Even in SQL, the one popular model that does support an entity-attribute distinction, it is declared positionally, not by requiring a special character at each reference. Constantly maintaining a mostly irrelevant distinction while writing addresses is going to confuse developers, as I think Animesh raised at the last meeting. The only use case is overloading an entity and an attribute definition with the same name at the same level, which would be even more confusing and better avoided. I'm sorry to raise this again, but I strongly feel we should get it right now as changing later is going to be much more difficult. If we do need entity-attribute distinction, we can declare it at the dictionary level, with no penalty other than having to throw an error on attempting attribute-only usage on an entity or vice versa, which is the same thing we'd do whenever a developer gets the angle bracket syntax wrong.

Joseph

On Nov 12, 2013, at 12:25 AM, Drummond Reed <drummond.reed@xdi.org> wrote:

Per my last message, the work that Markus and I did this weekend to analyze Joseph's proposal about using the empty address to represent the outer root took us down the path of exploring its impact on dictionary syntax. Although in the end it did not result in any changes, it did give us experience with using the new + dictionary syntax proposal.

What we both noticed is that using requiring an extra layer of context for all dictionary entries seems to add more confusion and complexity than it solves.

That forced us back into once again looking at some form of bracketing syntax, even though we have run out of bracketing characters.

So we revisited Markus' proposal to use a pipe, |, as the dictionary bracketing syntax.

After working with it for an hour yesterday, I was very pleased. Even though a pipe character is not a left/right bracket syntax, when used that way it reads almost as cleanly as parentheses, square brackets, or curly brackets. For example:

|<+name>|/$is+/$string+
|<+name>|/$is()/|<+first>|

But by far the biggest advantage is that by using pipe as a bracket, dictionary syntax will work the same way as all the other bracket syntax we have defined (root, collection, attribute, variable).

So I am withdrawing my previous proposal to use the + context for dictionary syntax, and replacing it with a proposal to use pipe as the dictionary bracket syntax. Note that I have updated https://wiki.oasis-open.org/xdi/GraphModelStructure to reflect this.

Thoughts?

=Drummond

xdi message