[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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]