Subject: Re: [scim] Conditional Patch

From: Ganesh and Sashi Prasad <[email-masked]>
Date: Sat, 1 Sep 2012 10:32:32 +1000

Kelly Grizzle wrote:
> Yes - I have looked at this also and think there is some good stuff here.
 It is similar to what Ganesh proposed for PATCH but limits the verbs and
(as you pointed out) relies
> on JSON Pointer rather than unique identifiers.

> I agree that JSON Pointer may not be the way to go.  My primary concern
is the use of indexes to address list elements (this is always where things
get tricky, isn't it?)
> since list indexes are not very stable.

I have been following Leif's advice to write up an Internet Draft and it is
underway, but I thought I would share my thinking early on two aspects.

1. I take on board the requirement to support _some_ multi-valued
attributes, but I would also like to combine that with addressability for
all values. So my ideal data structures are now three:

a) Nested dictionaries, where every value has its own key
{ "fully" : { "qualified" : { "key" : "value" } } }
Example of reference: "fully.qualified.key"

b) Fixed-length arrays, where the index can be assumed to be stable
"timesheet" : [ "8.0", "8.0", "4.0", "0.0", "8.0"]
Example of reference: "timesheet[2]"

c) Sets, where all values in the list are assumed to be unique (they should
also be simple, i.e., whole numbers or strings, not dictionaries or arrays)
"categories" : ["drama", "action", "comedy"]
Example of reference: "categories.drama"

(All other lists will unfortunately have to be turned into dictionaries
with server-generated keys, which could be in sequence if order is
important.)

Now we can still use the 5 simple (and unambiguous) verbs (INCLUDE, PLACE,
REPLACE, FORCE and RETIRE) to manipulate the resource at any level of
granularity.

2. I wonder why there is a special key called "meta". Isn't everything
meta-information, except the resource itself? I see the document as a soup
of meta-tags, with just one of them referring to the resource
representation. So this turns the model inside-out, so to speak.

If we do this, conditional expressions can be painlessly introduced. An
example may illustrate what I'm thinking. (Ignore the leading underscores -
I'm using that as a conventional for the protocol's own keywords and
server-generated keys as opposed to the resource's original keys.)

Assume a resource (/Toys.959d8cc5-0a64-4c7a-bcf6-38758d784d7a) with this
structure:

{
    "item" : "automobile",
    "parts" : {
        "_40e1f8b2101b" : "wheels",
        "_63ac7da834ff" : "engine",
        "_9d7e0fcc70a3" : "upholstery",
        "_a2ff51106dea" : "body"
    },
    "price" : {
        "currency" : "AUD",
        "amount" : "10.00"
    }
}

A conditional update of the price could look like this:

PATCH /Toys.959d8cc5-0a64-4c7a-bcf6-38758d784d7a

{
    "_verb" : "REPLACE",
    "_key" : "price.amount",
    "_expected" : "< 15.00",
    "_value" : "15.00"
},

We can also think of a separate "_condition" tag that refers to any
expression, not just the value of the attribute being updated.

Regards,
Ganesh