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] Multiplicity questions
I understand (and understood) your point. But I don't think that's enough. Can you also show that the uses cases without dictionary syntax are invalid or not useful? 

- Mike




On Tue, 3 Jul 2012, Drummond Reed wrote:


Mike,

First, multiplicity is not "my specific goal". Multiplicity is an inherent
issue with all data representation formats. XML, JSON, and RDF all deal
with it in their own way.

Secondly, multiplicity is one of the areas where structure meets semantics.
The proposed multiplicity syntax is a way to represent the semantics
associated with cardinality.

I fully grant you that the syntax of XDI statements using multiplicity
looks "more confusing" than without it. But that's a little like saying
English would be a lot simpler if we didn't have to worry about the
singular and plural forms of nouns.

Of course it would. But English has singular and plural forms of nouns
because the expressive power of being able to precisely express when you
mean one specific instance and when you mean a collection of instances has
proved to be broadly useful to English speakers.

Take a read through the Motivations section of the Multiplicity proposal:

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

These are the reasons that XDI developers need the expressivity of
multiplicity syntax just like English needs singlar and plural forms of
nouns. I didn't create that list of requirements. They have been
articulated by developers who have been part of the XDI TC for the past 8
years.

Are you saying that you don't think these requirements are important?

=Drummond

On Tue, Jul 3, 2012 at 6:33 AM, Michael Schwartz <mike@gluu.org> wrote:



I strongly object to making the graph look even more confusing by
requiring this extra syntax to accomplish your specific goals.

- Mike




------------------------------**-------
Michael Schwartz
Gluu
Founder / CEO
office: +1 646-810-8761
mike@gluu.org


On Mon, 2 Jul 2012, Drummond Reed wrote:

 I had a long discussion with Markus today about multiplicity. Here's where

we came out:

  1. 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.
  2. 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:
     1. 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.
     2. 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<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.**oas**is-open.org <http://oasis-open.org><
http://lists.**oasis-open.org <http://lists.oasis-open.org>>
<xdi-**unsubscribe@lists.**oasis-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<
http://open.org>
<xdi-unsubscribe@**lists.**oasis-open.org<http://lists.oasis-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<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

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