This page documents reasons why we are not using a particular technology or approach. It is there to remember rationale behind the decisions even long after the decisions were made.
Service Provisioning Markup Language (SPML) was considered as one of the options for internal interfaces and "universal" data model. The initial idea for a data model was to use account-resource part of the SPML model. Unfortunately, standard SPML does not define any specific schema for PSOs (provisioning objects) such as accounts and roles and groups. There is a draft of "standard schema" from 2007, but that is far from finished. The schema draft received a lot of critique from OASIS provisioning TC members, but then suddenly the work of entire TC stopped. The SPML TC seems to be non-functional to this day. There is an attempt to revive the specification effort, but there is little hope that it would achieve anything practical.
The lack of standard SPML schema will mean that we would need to create our own schema and that midPoint won’t be interoperable with other systems unless they adapt to midPoint schema.
SPML 2 schemas are also not valid, they hit the Unique Particle Attribution XSD constraint. Therefore they are not usable for us in the normative form and we would need to modify them (as essentially everybody does). But if a standard needs to be twisted in order to be usable, what is the real benefit of such standard?
The SPML is fundamentally broken as it is following the "premature standardization" anti-pattern. E.g. SPML 2 was standardized without any proof that it actually works, even with non-valid schemas (a drawback that could be trivially avoided). That’s wrong. There needs to be working code first, standard second.
The decision for midPoint is to use custom interface that is following some of the good characteristics of SPML design. Using a custom interface gives us faster development cycles - no need to "tweak" standard or be limited by it.
We can still use (modified) SPML externally if needed.