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] question on singletons


I tend to support approaches that make the standard "as simple as possible, but no simpler" and "easy to use for developers."

Can we create conformance requirements that make the $set, $append (new/required), $delete and any other write operations to manage singletons and collections transparently to developers by default wherever possible, but also allow developers modes of granular control?

Dan


On Thu, Jul 10, 2014 at 12:05 AM, Joseph Boyle <planetwork@josephboyle.net> wrote:
My previous understanding had been that collection vs. singleton was up to schema designers and not an automatic conversion on inserting a second item, and that we also had an example pattern where a person had multiple phone numbers with different labels and could manually assign the singleton for “the person’s phone number” to point to one of these numbers.

On Jul 9, 2014, at 8:57 PM, Markus Sabadello <markus.sabadello@gmail.com> wrote:

Also adding this to the XDI TC agenda.

Yes there seems to be a bug with the graph editor if it displays both literals as a single node.

Markus



On Wed, Jul 9, 2014 at 6:29 PM, Davis, Peter <Peter.Davis@neustar.biz> wrote:
inline

On Jul 8, 2014, at 16:41 PM, Markus Sabadello <markus.sabadello@gmail.com> wrote:

> Hi Peter yes this is an interesting situation and it has come up a few times in the past.
>
> I think an xdi server should be able to do this automatically, i.e. convert a singleton into a collection.
>
> We might need a specialized operation for this, e.g. [$set] instead of $set or something like that. Also, such an operation should be able to work with both ordered and unordered collections.

Ok, then we need to mention that in the Messaging spec, i think.

>
> I don't think all attributes should always be collections, I am confident we can make it so a client does not have to know the structure of the attribute when constructing the $msg.
>
> So the server would create the [<#email>] as you describe it. In addition it would change the <#email> to have a $ref to to the original value which is now inside the collection.
>
> This $ref I think would take care of Dan's concern. A client with a link contract for <#email> would still be able to access it after the change.
>
> I don't understand your point about $set and $get permission. Obviously for adding an email address you would need $set.

somewhat mute if the server handles this. the point i was trying to make was if a client didn’t know ahead of time (via a $get) that the target attribute of a $set message was a collection, a $set message with =example<#email>&/&/“me@example.biz” would fail (or would it? or should it?). interestingly, the following appears to be valid (though the graph editor might be doing the wrong thing [1] as it lumps the 2 literals as the same node, when it really is not):

=markus<#email>&/&/"markus.sabadello@gmail.com"
=markus[<#email>]<@0>&/&/"markus.sabadello@gmail.com

[1] http://neustar.github.io/xdi-grapheditor/xdi-grapheditor/public_html/index.html?input=http://xdi2.projectdanube.org/XDIOutput?outputId=8f5234dd-3f7d-46e7-b6f8-b801a0e87d13

>
> I agree with our current signatures proposal(s) we might have to recreate signatures. That seems not ideal.

I agree it is not ideal, especially if the signature was made by a third party, in which case the server has no way to recreate the signature.

=peterd


>
> Markus
>
> On Wednesday, July 9, 2014, Davis, Peter <Peter.Davis@neustar.biz> wrote:
> > In doing some additional exploration of corner cases for signatures, I came up with the following scenario:
> > 1] a graph contains the singleton: =example<#email>&/&/“me@example.biz
> > 2] time passes, and the subject needs to add a new, additional, email to the graph: “me@example.org
> > what i assume will transpire is:
> > 1] delete the singleton =example<#email>&/&/“me@example.biz
> > 2] create a new email collection:
> > =example[<#email>]<@0>&/&/“me@example.biz
> > =example[<#email>]<@1>&/&/“me@example.org
> > how does an XDI service know ahead of time this is what needs to be done, or is that somehow automatically handled by the graph server? if the former, what happens if the client does not have a $get policy, but does have a $set policy in place?
> > this means (among other cascading consequences), that if a signature/encryption was present on the original singleton, a new signature/encryption values need to be generated for one or both of the new triples.
> > =peterd
> > Peter Davis: Neustar, Inc.
> > Distinguished Engineer, Director, Neustar Foundry
> > 45980 Center Oak Plaza Sterling, VA 20166
> > [T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd
> >
> > The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.
> >

Peter Davis: Neustar, Inc.
Distinguished Engineer, Director, Neustar Foundry
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ [X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.







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