feat: support dot notation for add and replace ops

[Valodim]

Hey there! Thanks for taking a stab at scim-patch in golang 👍

I noticed that there is no support for the "dot notation", which is prominently used by MS Entra. Here is an example patch operation from their validator:

    {
      "op": "replace",
      "value": {
        "externalId": "39be3336-3e88-4c41-80b7-c654ab698a5e",
        "active": true,
        "name.familyName": "Lincoln",
        "name.givenName": "Greg"
      }

The name.familyName here should be applied to the familyName subattribute of name. This dot notation has no examples inthe spec unfortunately, but is mentioned in Section 3.10. There are also some examples of how dot notation is used in the entra scim compatibility docs, see the "Requests to replace multiple attributes" example with the new feature flag (now enabled by default, I believe).

This PR adds support for the dot notation and some tests for it. I'm not sure the way it is implemented fully matches your architecture, but if it doesn't perhaps this can serve as a starting point.

I also validated that it fixes the relevant step of the entra scim validator.

[ivixvi]

Hey, thanks a lot for this great contribution 👍 — really appreciate you taking the time to work on scim-patch and especially for including the helpful references!

You're right that the SCIM RFC doesn't explicitly define dot notation usage in the value field, but after reviewing the Entra ID documentation and validator behavior, I agree that supporting this is a meaningful enhancement. I'd like to move forward with incorporating it.

I’ve added two points from an architectural perspective — please take a look and let me know your thoughts.

Again, thanks for the thoughtful PR and tests — looking forward to collaborating more!

[ivixvi]

In the current design, we generally delegate value resolution and movement to scope.go or scimpatch.go, so I think it would make sense to handle dot notation there as well.

My current thought is that it might be most natural to invoke applyDotNotation inside pathUnspecifiedOperate in scimpatch.go, to resolve and re-map the paths accordingly.

[Valodim]

I had also considered that, but it seemed like I would just move it to all call sites of Direct then.

Do you think this only applies to the pathUnspecifiedOperate flow? It does for entra (I believe), but in theory it could apply in cases that have a path as well 🤔

If we want to support this for ops with no path only, moving it up to scimpatch.go is the simple way to go.

[ivixvi]

it seemed like I would just move it to all call sites of Direct then.

in theory it could apply in cases that have a path as well 🤔

Yeah, exactly... 😢
I totally get that calling resolveDotNotation before every use of Direct doesn’t feel great either.

That said, I also feel a bit uneasy about baking that logic directly into Operators just for the sake of simplification.

As an alternative, how about introducing a wrapper layer around Direct?

[Valodim]

Gave it a shot, it's actually not so bad. We add it to all call sites, but now it doesn't have to be in every operator. So overall, it's fine imo

PTAL

[ivixvi]

Thanks for the update!

I think so too.
If any issues come up in future changes, we can revisit it then.

[ivixvi]

LGTM

Thanks again for taking the time to work on this!