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] XDI article for PDJ


Thanks all for the good ideas, I've incorporated most of them.

Normally the PDJ articles are not made public on the web, but I'm sure it would be okay to put it up somewhere.

Markus

On Sat, Jul 7, 2012 at 12:27 AM, Drummond Reed <drummond.reed@xdi.org> wrote:
Yes, I definitely favor the name change, however when I raised with OASIS they said it would be a huge hassle. I guess I could raise it with them again and see just how huge of a hassle it would actually be.

All in favor say aye.

=Drummond 


On Fri, Jul 6, 2012 at 2:43 PM, Joseph Boyle <planetwork@josephboyle.net> wrote:
Drummond,  a few months back we discussed making XDI stand for simply eXtensible Data Interchange, you were enthusiastic about the idea, I don't remember anyone objecting, but we never formally followed through on it. If we want to do this, it might be good to do it now as we are about to publish articles and specs.

SMTP transport is an interesting idea - would that simply mean you send an XDI message to a specified email address, and get the reply emailed back?


On Jul 6, 2012, at 1:51 PM, Drummond Reed wrote:

Markus, as we discussed on the call today, congrats on an excellent article. I read through the whole thing and have just a few minor suggestions:
  • In the XRI section, you say, "For example, if the XRI =alice is used within XDI data, then an XDI processor can immediately tell that it refers to a person (because the = symbol is used)." To be semantically precise, what an XDI processor can tell from the = global context symbol is that it this branch of the XDI graph is controlled by an individual person. In other words, the =namespace is specified to be for identifiers controlled by individuals, but which may represent any resource that the individual assigns the resource too. So, for example, =alice in the XDI graph could be a cat (i.e., the XDI "is a" statement could be =alice/$is+/+cat). So, although the vast majority of =names and =numbers will identify resources that are people, you can't make that assumption just on the basis of an =name or =number alone.
  • Since your example graph includes multiplicity syntax for $!(+tel), you might add a line explaining that +tel is a phone number, and $! is a way of expressing that this is a single canonical instance of a literal phone number and not a collection of phone numbers (which would be $*(+tel) ).
  • In the XDI Messaging section, you say, "XDI messages can be sent over different protocol bindings, such as HTTP, WebSockets, or SMTP." I used to say the same thing, but practically speaking, I'm not sure anyone will ever do a XDI SMTP binding. So you might want to make the third example XMPP, since that's a protocol that's on the TC's list for a binding.
  • In your XDI Link Contracts section, you way, "In its simplest form, a link contract consists of two components: One or more sender XRIs identifying the parties who are given permissions by the link contract (the “assignees”); and one or more XDI operations and XDI addresses, specifying what operations are allowed on what parts of a graph." I summarize a link contract as always having three components, because without the link contract node itself, the link contract would not have a subject. So I would suggest: "In its simplest form, a link contract consists of three components: the link contract XRI that uniquely identifies it in the graph, one or more sender XRIs identifying the parties who are given permissions by the link contract (the “assignees”); and one or more XDI operations and XDI addresses, specifying what operations are allowed on what parts of a graph."
  • Given the discussion on this morning's telecon, I think the following might give the wrong impression: "Some work is being done to pursue the vision of a tight relationship between OpenID Connect and XDI, which means that in a global, distributed ecosystem, OpenID Connect would provide identity federation, and XDI would provide data federation." I would suggest softening this slightly to, "Some work is being done to obtain the maximum synergy between OpenID Connect and XDI. This would enable building a global distributed ecosystem in which OpenID Connect could provide the identity federation and XDI could provide the data federation."
  • Lastly, in your side box text, you say, "Like its predecessor, it also assumes triples as its foundation, but also includes a strong notions of contextuality." I think you meant "a strong notion" (singular) or "strong notions" (plural). Or, another suggestion would be to characterize it this way: "Like its predecessor, it also assumes triples as its foundation, but more precisely defines the definitions and relations between contexts, and also clearly establishes the special roles of root nodes and literal (leaf) nodes."
Hope this helps - again, congrats on what is a great article.

Will this article be available/publicly reference-able on the web?

Thanks,

=Drummond  

On Tue, Jul 3, 2012 at 3:12 PM, Markus Sabadello <markus.sabadello@xdi.org> wrote:
Find attached the current draft of the XDI article for the next issue of the Personal Data Journal.

If you have any suggestions, please send in the next few days.
Also feel free to annotate the docx file and send back to me.
Perhaps we could have a quick (5 min) talk about it on the Friday XDI TC call.

Markus



---------------------------------------------------------------------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xdi-help@lists.oasis-open.org









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