Re: [xdi] Multiplicity questions

The member instances of a collection (whether of multi-valued contexts or multi-instance contexts) are unordered. If ordering is needed, it must be explicitly added to the graph via $* statements.
The requirement is only that every member instance of a multiplicity collection have a unique i-number. It is up to an XDI server's own policy how this i-number is assigned. The two basic choices are:

Assign a locally unique i-number, in which case the server must either maintain a counter or some other algorithm to enforce uniqueness and non-reassignability.
Assign a UUID, in which case it is trivial for the server to maintain uniqueness and non-reassignability (and even clients can assign i-numbers to new member instances).

The other conclusion Markus and I came to is that enforcement of multiplicity syntax is not optional. Either it works everywhere in the graph, or its not going to be interoperable. This of course includes XDI messaging -- either all XDI messages use multiplicity syntax, or none do.

So I updated the multiplicity proposal page and marked it High Priority:

https://wiki.oasis-open.org/xdi/XdiMultiplicity

I also included examples of using UUIDs as member instance i-numbers.

=Drummond

On Mon, Jul 2, 2012 at 11:03 AM, Michael Schwartz <mike@gluu.org> wrote:

To me, the question boils down to when the server returns order results, how does it order them. From this perspective, it doesn't matter if the values are [1,2,3,4...] or [10,99,400,500...].

And we certainly don't want to make delete operations have to change the values of other nodes in the tree. This would be hugely expensive.

thx,

Mike

On Mon, 2 Jul 2012, Drummond Reed wrote:

I believe interoperability of multiplicity is going to be one of the keys
to interoperability of XDI as a whole. That's why it's been such a focus of
mine.

The question Markus asks is a key one with regard to interoperability: how
does a client add a new instance to a set of instances?

Markus, what about the pattern of the client asking to set a new instance
using an XDI variable, and the server setting the i-number of the new
instance? That way each server can manage the i-number set in the way
that's optimal for that server and that set.

Mike, when you say, " the values are ordered lowest-->highest, not
sequentially", what do you mean by "lowest-->highest"?

I think the rule should be only that each instance within the set has a
unique i-number in the set, not that there is any implicit order at all
(explicit order can be added with $* statements). However if we are going
to specify an implicit order, we should be absolutely clear about what that
rule is.

=Drummond

On Mon, Jul 2, 2012 at 10:39 AM, Michael Schwartz <mike@gluu.org> wrote:

Markus,

I think the plan was to say that the values are ordered lowest-->highest,
not sequentially. So there was never any assumption on my part that all
integers would be present.

thx,

Mike

On Mon, 2 Jul 2012, Markus Sabadello wrote:

Okay, makes sense to me.

In this case however the spec should at least say that the $!1, $!2, $!3
pattern is just one possible way to do it, and that GUID-style I-Numbers
are also possible.

And no implementation should rely on the $!1, $!2, $!3 pattern, or we'll
have interoperability problems.

Markus

On Mon, Jul 2, 2012 at 7:24 PM, Michael Schwartz <mike@gluu.org> wrote:

Markus,

I think this is a question about convention. I don't think we need any
proposal in this area.

- Mike

On Mon, 2 Jul 2012, Markus Sabadello wrote:

Example:

=markus$*(+email)$!1/!/(data:,****aaa)
=markus$*(+email)$!2/!/(data:,****bbb)
=markus$*(+email)$!3/!/(data:,****ccc)

I was wondering.. If you first delete let's say the $!2 value, and then
add
a new value, does the $!2 get recycled?
Or does the counter always keep going up, i.e. $!4 would be issued, even
if
$!2 is unused?

I think I-Numbers should not be recycled for new values, and new ones
should always be issued.

So, I think an extra statement should be introduced to remember the
I-Number of the last value:

=markus$*(+email)/$!/$!3 <-- last I-Number

With this statement it gets much easier and more efficient for the
server
to add a new value of +email.

Or perhaps it would be even better to used GUID-style I-Numbers, then
the
question of increasing the counter becomes obsolete.
Or perhaps the spec should not specify this, i.e. you could either use
sequential I-Numbers, or GUID-style ones, whatever you prefer.

At XDI2 we need this for implementing link contracts and the policy
context
nodes, which use the multiplicity format.

If this looks right, I'll create a Proposal page.

Markus

------------------------------****----------------------------**

--**---------
To unsubscribe, e-mail: xdi-unsubscribe@lists.oasis-****open.org<http://open.org>
<xdi-unsubscribe@**lists.oasis-open.org<xdi-unsubscribe@lists.oasis-open.org>

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

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

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

xdi message