Re: [xdi] Proposed resolution of attribute contextualization rule

[Dan Blum <dan@respectnetwork.net>]

It seems to make sense. 

But I wonder what we're getting ourselves into. The example depicts a simple path. Are there more complex paths that could get perversely complex? Is it time to model a full personal cloud schema for actual applications in XDI to see whether we're close to the answer to or going nowhere?

The concept of attributes describing each other goes far beyond my directory and database lore. Although there is a sense of it hierarchical directory inheritance, which can affect schema, access control and other policies.

Contextualization in XDI seems similar. Do we also have contextualization at the entity level as they have with directories?

What if any issues are there with multiple inheritance when references are used? This is a problem that directory people could never solve.

Dan

On Tue, Nov 12, 2013 at 3:37 AM, Drummond Reed <drummond@respectnetwork.com> wrote:

A second unresolved issue from last Friday's telecon was attribute contextualization. In short, the question was which of the following was correct:

#1: =markus+first<+name>&/&/”.....”

#2: =markus<+first><+name>&/&/”.....”

On the TC call I argued for #1, because +first itself was not an attribute. However in discussing it this weekend with Markus I realized there was a much stronger argument for #2: to contextualize an attribute you MUST use only other attributes because all attributes must ultimately describe the entity they follow.

In other words, <+first> MUST be an attribute in the example above because <+name> is ultimately an attribute of =markus, not of +first.

If everyone agrees, then we just discovered another key rule of using XDI syntax that we will express in XDI Core.

=Drummond