Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0)

From: Kelly Grizzle <[email-masked]>
Date: Tue, 15 May 2012 21:19:46 +0000

Sorry for the late reply - just digging through some old emails.

The "schemas" attribute combined with the extension-specific sub-attributes is meant to be a JSON representation of XML namespaces.  The XML representation does disambiguate the object type:

<Contractor xmlns="urn:scim:schemas:core:1.0" xmlns:corporate="urn:scim:schemas:ext:corporate">
  ...
</Contractor>

Maybe the JSON representation needs something akin to the root element name in the XML representation.  Perhaps an "objectType" attribute?

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, April 24, 2012 1:04 PM
To: Samuel Erdtman
Cc: [email-masked]
Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0)

I think there may be a more complex issue.  The URN listed is usually the extension namespace and not the extension object.

So if you defined:

urn:scim:schemas:ext:corporate as an extended schema and within that defined an "employee" and a "contractor" objects, then the following json would be ambiguous

> {
> "schemas":["urn:scim:schemas:core:1.0", 
> urn:scim:schemas:ext:corporate],
> "userName": "kalle",
> "urn:scim:schemas:ext:corporate": {
>   employeeNumber: "abc123"
> }
> }

Unless you can tell by the attributes, it is unclear whether the User above is a "contractor" or an "employee".   Should the schema URN in the extendsion be the object URN?  --> urn:scim:schemas:ext:corporate:contractor

Phil

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

On 2012-04-24, at 3:47 AM, Samuel Erdtman wrote:

> Since extensions are not contained within an extension node there are 
> the possibility of conflicts with existing and future attributes.
> Would it be desirable to put extensions within an extension node 
> (since extensions as Kelly mentioned are defined by URN:s conflicts 
> are in worst cases rare).
> Today a user with two extensions could look like this { 
> "schemas":["urn:scim:schemas:core:1.0", urn:scim:schemas:ext1, 
> urn:scim:schemas:ext2],
> "userName": "kalle",
> "urn:scim:schemas:ext1": {
>   employeeNumber: "abc123"
> },
> "urn:scim:schemas:ext2": {
>   employeeNumber: "123abc"
> }
> }
> Would it be better to change it to this { 
> "schemas":["urn:scim:schemas:core:1.0", ext1, ext2],
> "userName": "kalle",
> "extension": {
>   "urn:scim:schemas:ext1": {
>      employeeNumber: "abc123"
>    },
>   "urn:scim:schemas:ext2": {
>     employeeNumber: "123abc"
>   }
> }
> }
> 
> Thoughts?
> (for details see the thread
> http://www.ietf.org/mail-archive/web/scim/current/msg00235.html and 
> the http://www.simplecloud.info/ page) //Samuel 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

_______________________________________________
scim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Tue, 15 May 2012 14:41:53 -0700

Either way works for me. What is more json friendly?

Phil

---

From: Kelly Grizzle <[email-masked]>
Date: Wed, 16 May 2012 13:32:53 +0000

I have seen it both ways - a top-level object wrapper and an attribute.

  { "Contractor": { "id": "1234", ... } }

vs

  { "id": "1234", "objectType": "Contractor" }

I prefer the latter because it looks cleaner (IMHO) and is in line with many other programming languages (eg - Object.getClass()).

--Kelly

-----Original Message-----
From: Phil Hunt [mailto:[email-masked]] 
Sent: Tuesday, May 15, 2012 4:42 PM
To: Kelly Grizzle
Cc: Samuel Erdtman; [email-masked]
Subject: Re: [scim] Conflict with extensions (consider for SICM 2.0)

Phil

On 2012-05-15, at 14:19, Kelly Grizzle <[email-masked]> wrote:

> <Contractor xmlns="urn:scim:schemas:core:1.0" 
> xmlns:corporate="urn:scim:schemas:ext:corporate">
>  ...
> </Contractor>
> 
> urn:scim:schemas:ext:corporate as an extended schema and within that 
> defined an "employee" and a "contractor" objects, then the following 
> json would be ambiguous
> 
>> {