Subject: Re: [scim] Use of value for complex multi-valued attributes

From: Scott Fehrman <[email-masked]>
Date: Tue, 14 May 2013 21:44:11 -0500

+1

On May 14, 2013, at 2:01 PM, [email-masked] wrote:

> 
> Maybe we should indicate that "value" is NOT to be used with complex attributes?  Otherwise, I could see a lot of inter-op issues as people decide whih combinations or specific attribute is the significant attribute when it comes to complex attributes.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [email-masked]
> 

Scott Fehrman, [email-masked]

---

From: Alex Redston <[email-masked]>
Date: Wed, 15 May 2013 09:28:08 +0100

Phil,

I would have to agree with your analysis, this is a little too open to 
interpretation

The type and primary attributes both seem to be just pieces of arbitrary 
metadata, if we are going to have metadata like primary and type then 
why not simply have a structure for generic metadata:

Then you could have whatever metadata was useful to provide context, 
like "type", "order", "primary", "depreciated". By all means be 
prescriptive on the most common metadata like "type" and "primary" to 
aid interoperability but make the model more extensible - what do you think?

"addresses": [
   {
*"metadata": {*
          "type": "work",
          "primary": true
      }
*"value": {*
          "streetAddress": "100 Universal City Plaza",
          "locality": "Hollywood",
          "region": "CA",
          "postalCode": "91608",
          "country": "USA",
      }
    },
    {
*"metadata": {*
          "type": "home"
      }
      "value": {
          "streetAddress": "1 Western Drive",
          "locality": "Hollywood",
          "region": "CA",
          "postalCode": "91608",
          "country": "USA",
      }
   }
    {
*"metadata": {*
          "type": "home",
         "depreciated": "true"
      }
      "value": {
          "streetAddress": "2 Beverly Drive",
          "locality": "Hollywood",
          "region": "CA",
          "postalCode": "91608",
          "country": "USA",
      }
   }

]

Alex

Alex Redston
Technical Architect
Switch Research

On 14/05/2013 20:01, [email-masked] wrote:
> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/scim
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send scim mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/scim
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of scim digest..."
>
>
> Today's Topics:
>
>     1. Use of value for complex multi-valued attributes (Phil Hunt)
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

-- 
Alex Redston

Technical Architect, Managing Director
Switch Research Limited

+44 1328 838821
+44 7973 320795

---

From: Phil Hunt <[email-masked]>
Date: Wed, 15 May 2013 09:12:16 -0700

Alex,

I guess the issue is avoiding too many normative changes.  Also, I would prefer getting too "wordy" or having too much structure. Also, so far "meta" is used for things unrelated to the data values (e.g. modified date) and usually not modifiable by clients.  I admit, "type" and "primary" has a meta feel, but clearly still client-controlled.

Having value contain sub-attributes makes some sense from a truly consistent view of defining multi-valued attributes. However, I believe the original intent is that "value" always contain a string value.

Others may be able to give the original 1.0 perspective on this. There's often good reason for these things.

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-05-15, at 1:28 AM, Alex Redston wrote:

> Phil,
> 
> I would have to agree with your analysis, this is a little too open to interpretation
> 
> The type and primary attributes both seem to be just pieces of arbitrary metadata, if we are going to have metadata like primary and type then why not simply have a structure for generic metadata:
> 
> Then you could have whatever metadata was useful to provide context, like "type", "order", "primary", "depreciated". By all means be prescriptive on the most common metadata like "type" and "primary" to aid interoperability but make the model more extensible - what do you think?
> 
> "addresses": [
>   {
>      "metadata": {
>          "type": "work",
>          "primary": true
>      }
>      "value": {
>      "metadata": {
>      "metadata": {