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] Re: [External] [xdi] Continuing the $is discussion


I need to write up the example Markus requested still, but here are some thoughts in response.

Equivalence links can be needed between any two XDI context nodes, regardless of whether they are identified with i-names or i-numbers.
I can see the use case for i-name to i-name, i-name to i-number, but not i-number to i-name, or really i-number to i-number (see next).

There is a clear use case for needing to express equivalence between two i-numbers (the "merge accounts" use case that Les and I encountered in doing XRI registry design).
Where can I find the write up on this use case within the XDI TC wiki, or Kavi?  

We need to be able to control equivalence link resolution behavior both on the endpoint site and the client side. So having parallel $is and $get statements is pretty attractive.
Why do we need to control it on the client side? 

To me additional variations of $get within the core spec is not attractive at all.  We are continuing to add complexity when I'd like to be at the stage where we are simplifying in preparation for submitting for ratification. 

The rule I would suggest at this point for XDI is that if it satisfies the most common 80% of the use cases, ship it.  This is harder because we never fully gathered our use cases within the TC, each of us has our cases developed for the domain we intend to use XDI on, spread over github projects, other mailing lists (XDI2), and conference transcripts (IIW).  We could rectify that somewhat. If anyone wants to, they could post email(s) to the XDI list with the following characteristics:
  1. Subject starts with UserStory:
  2. Subject ends with a title for the user story
  3. Body starts with the following, filling in {} blanks as appropriate
        As a {end user role}, I want to {action to be enabled}, so that {end user goal}
  4. Body ends with the following
This is done when after I {action to be enabled} the following conditions are true:
            {bulleted list of definition of done here}


We can write XDI Core so that we build in extensibility, which means handling the other 20% later is doable.  If however we keep adding complexity we will miss another deadline.



On Wed, Nov 14, 2012 at 10:12 AM, Drummond Reed <drummond@connect.me> wrote:
Guys, I am concerned about having any XDI verbs that would discriminate between XDI nodes on the basis of whether the identifier of the node is an i-name or i-number. But I'm tied up in meetings this morning so I'll join the thread further this afternoon.

=Drummond 


On Wed, Nov 14, 2012 at 3:41 AM, Markus Sabadello <markus.sabadello@gmail.com> wrote:
Hi Bill,

I kind of like $is and $id, it sounds intuitive. On the other hand, I think the reason why on the last XDI TC call we thought it would be better to extend $is was because $is, $is!, $is$private, or whatever, would have the same (or very similar) semantic meanings, the only difference would be how the server resolves/expands/substitutes them.

So in your proposal, there would only be a single $get operation, with no variants, right?

I think it would be great if you could give an example, similar to ones I tried to do in my demo app. Maybe that example could include a graph, a $get message, and the message result? I think that would really help understand your proposed $is and $id functionality.

I don't understand how a link contract can "control access to $id statements differently than $is". In my understanding of link contracts, they apply to XDI addresses and their associated subgraphs, but not to individual relational arcs.

You say that I-Names can have "properties", also you say that you could have relations between I-Names such as =al/$is/=bob. What happens if somebody else registers =al? I thought the whole point of I-Numbers was to have all the data attached to them, rather than attached to I-Names.

Another question.. There are XRIs that are neither I-Name nor I-Number. Would you advocate for a need to be able to assert equality between such XRIs? The $is relation as it is currently understood can be used between any XRIs, and the fact that certain XRIs are I-Names or I-Numbers, that by itself is basically a design pattern but doesn't trigger any special functionality or reasoning on the XDI layer.

This is a typical situation where we would need to be all in the same room for a few days with whiteboards etc, in order to figure it out :) But again I think examples would be useful..

Markus

On Tue, Nov 13, 2012 at 3:57 PM, Barnhill, William [USA] <barnhill_william@bah.com> wrote:

The proposal Markus sent covers all the possibilities with different syntax.  I think the syntax you propose Markus is well thought out and covers all the possibilities.

 

Question is… Is that more important than keeping our API simple?  

 

By that I mean that I think we can streamline the number of verbs needed back down to two, and make our API much simpler to understand.

 

In his recognized presentation “How to design a good API and why it matters” Joshua Bloch says APIs should be usable, even without documentation.

 

For these reasons I propose again that we solve this with three rules. Those three, updated a little here, are:

1) The predicate $is can only have subject and object that are each an i-name

2) The predicate $id can only have an i-name as subject and an i-number as object  (a variation on the second verb we’ve discussed on the list and on the call)

3) To indicate that =al is =bob you need =al/$is/=bob in the graph

 

This solves the identity leak problem, because the link contract can control access to $id statements differently than $is

This solves Drummond’s scenario, because $is is now only based on i-names.

 

The implications of this are that:

a) properties defined as under one i-name have a separate access list than those defined under another i-name, unless you have access to the $id statement, or to the statements with the i-number as the subject

b) properties defined under the i-number are visible only to the server and to those with access to i-number as the subject.

 

To connect two identities by an equivalent i-number you need $id statement access to the i-names of both identies, which means it requires authorization from both identities.

To walk all the identities under an i-number you need access to the statements with the i-number as the subject, then you use the inverse of $id.

 

Do we need a predicate to connect two i-numbers, i.e. one with i-number for subject and i-number for object?  I don’t think so, for two reasons

a) If there is a persistent identifier for a resource within the same data authority, then why are we creating a new persistent id within that authority

b) If the persistent identifier is at a 2nd data authority then it can be pointed at by an i-name at the first data authority, which If desired can point to an i-number using $id. This makes more sense to me as the local persistent resource is not the same as the resource at the 2nd data authority, the local resource is instead the data the local authority knows about that remote resource.

 

 

This still leaves a more fundamental decision: do we have implicit statements derived from reasoning rules in returned graph results?  Put more simply, does XDI have a reasoning required for any implementation, or is it an additional optional layer?  As most of you guess my vote would be to have reasoning as a core capability, requiring implicit statements be returned.  I do think there is a need to qualify a target graph in a request so that only explicit statements are used/returned.

 

Kind regards,

 

Bill Barnhill

Booz Allen Hamilton - Belcamp,MD

barnhill_william@bah.com

Cell: 1-443-924-0824

Desk: 1-443-861-9102

 

From: xdi@lists.oasis-open.org [mailto:xdi@lists.oasis-open.org] On Behalf Of Markus Sabadello
Sent: Saturday, November 10, 2012 7:34 AM
To: xdi2@googlegroups.com; OASIS - XDI TC
Subject: [External] [xdi] Continuing the $is discussion

 

During the last XDI2 and XDI TC calls, we considered how $is relations should behave.

 

One idea was that on the server side there could be a distinction between "public" and "private" links, or between "transparent" and "opaque".

Another idea was that a client could qualify its operations to request "expanded" or "compressed" responses.

 

I tried to summarize a few variants here:

 

The ideas there are that...

- $is would be a "public" / "transparent" link, i.e. visible to clients

- $is! would be a "private" / "opaque" link, i.e. not visible to clients

- $get would tell the server not to treat $is in any way special

- $get* would tell the server to follow $is links and return an "expanded" response

- $get! would tell the server to follow $is links and return a "compressed" response

 

I did an experimental implementation of this, just to see how it could work..

 

Not sure if all this functionality is required, or if the defaults should be different, or if the $is and $get qualifiers should be named differently.

But I hope this can help continuing the discussion..

 

Markus

 





--
You received this message because you are subscribed to the Google Groups "XDI2" group.
To post to this group, send email to xdi2@googlegroups.com.
To unsubscribe from this group, send email to xdi2+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 




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