[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Re: [External] [xdi] Continuing the $is discussion
Ok, finally getting back to respond to this thread.RE the proposal Markus mentioned, I have now written it up formally on the wiki as:The two equivalence links it proposes are $is (standard link) and $is! (compact link).The two $get forms it proposes are $get (standard graph) and $get! (compact graph).I think the rules for each are crystal clear -- please review it and see what you think.Bill, with regards to the $is and $id proposal, the issues I see are:
- Equivalence links can be needed between any two XDI context nodes, regardless of whether they are identified with i-names or i-numbers.
- 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).
- 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.
Let's discuss as is helpful on the list, and then hopefully we can close on this on Friday's telecon.=DrummondOn 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.=DrummondOn 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..MarkusOn 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
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]