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] Dictionary syntax proposal


On Thu, Oct 17, 2013 at 8:49 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
I feel a little bit uncomfortable to have to use two contexts for a single definition, but I see no reason why it wouldn't work :)

Markus, you are correct, I forgot to explain that is what make this proposal work—that it adds an extra context.

There are two sides to that. The downside is that it means every definition adds another node to the graph—an increase in complexity. This is somewhat offset because all the nodes in any one definition space share that same definition context, so that node is common to all of them.

The upside is that the definition context node is 100% standardized everywhere and, like a value context node, identified by exactly one XDI context symbol.

So code that needs to recognize and parse definitions can just look for that one definition context node.
 

FYI this is what the current mapping file of the XDI2 Facebook connector looks like:

I believe that when you processed this "before" example you accidentally replaced the $ symbols with + symbols , i.e., the previous proposed syntax used a dollar sign before the cross-reference for each dictionary entry.

(https://facebook.com/)+(+(user))+(<+(name)>)/$ref/+(<+name>)
(https://facebook.com/)+(+(user))+(<+(first_name)>)/$ref/+(+first)+(<+name>)
(https://facebook.com/)+(+(user))+(<+(middle_name)>)/$ref/+(+middle)+(<+name>)
(https://facebook.com/)+(+(user))+(<+(last_name)>)/$ref/+(+last)+(<+name>)
(https://facebook.com/)+(+(user))+(<+(gender)>)/$ref/+(<+gender>)
(https://facebook.com/)+(+(user))+(<+(locale)>)/$ref/+(<+locale>)
(https://facebook.com/)+(+(user))+(<+(email)>)/$ref/+(<+email>)
(https://facebook.com/)+(+(user))+(<+(website)>)/$ref/+(<+website>)
(https://facebook.com/)+(+(user))+(<+(birthday)>)/$ref/+(<+birthday>)

I'm guessing after the change it would look like this:

Right on.
 

(https://facebook.com/)++(user)+<+(name)>/$ref/+<+name>
(https://facebook.com/)++(user)+<+(first_name)>/$ref/++first+<+name>
(https://facebook.com/)++(user)+<+(middle_name)>/$ref/++middle+<+name>
(https://facebook.com/)++(user)+<+(last_name)>/$ref/++last+<+name>
(https://facebook.com/)++(user)+<+(gender)>/$ref/+<+gender>
(https://facebook.com/)++(user)+<+(locale)>/$ref/+<+locale>
(https://facebook.com/)++(user)+<+(email)>/$ref/+<+email>
(https://facebook.com/)++(user)+<+(website)>/$ref/+<+website>
(https://facebook.com/)++(user)+<+(birthday)>/$ref/+<+birthday>

Markus



On Thu, Oct 17, 2013 at 12:38 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
After a good XDI Core editing session with Joseph tonight, we made the executive decision to adopt the dictionary definition syntax proposal discussed briefly on the last few telecons—namely, to use + syntax instead of $( ) syntax. I have updated the Graph Model Structure wiki page accordingly:


For the record, the reasons are:
  1. $( ) syntax was the only vestige of our former syntax that depended heavily on cross-references.
  2. I$( ) syntax is also the only syntax that required a prefix before a bracketing symbol (which makes it particularly complicated); all of the new bracketing symbol syntaxes we adopted do not use a prefix context symbol.
  3. + syntax is much simpler and can accomplish everything that $( ) syntax could.
  4. Leaving $( ) syntax undefined means it is available to define once we get to the XDI query language (for which I suspect it might be needed).
The rule with using + syntax for dictionary defintions is that the + symbol is BY ITSELF the dictionary definition context. Thus to define any entity or attribute, just put it in that context. Examples:
  • Entity singleton: +passport   Definition: ++passport
  • Attribute singleton:  <+tel>    Definition:  +<+tel>
XDI authorities can create their own personal, legal, or general dictionary namespaces spaces by prefixing their own XDI addresses with +. So, for example, if Neustar had its own definition of +<+tel>, the definition would be (using Neustar's cloud name):

           +@neustar+<+tel>

Then, once Neustar had defined this, I could use an instance of a Neustar telephone number like this:

            =drummond+@neustar<+tel>

Any thoughts before Joseph and I write this into XDI Core 1.0 WD01?

=Drummond 




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