SPML Approach Comparative Summary
This document is an attempt to summarize the similarities and differences between the current SPML proposal and the competitive proposal, and provide an overview of the arguments on both sides.  
Primary Differences
A small number of fundamental issues distinguish the two approaches:
1.	The object models differ significantly.  That is, the core schema in the current specification defines a set of operations that echo those found in the DSML specification.  The alternative proposal introduces types based on provisioning concepts and objects identified in the PSTC uses cases.
2.	The schema description languages are radically different.  The current SPML defines a schema description mechanism based on concepts familiar to users of LDAP/DSML, primarily object classes and attribute definitions.  The alternative proposes the use of XML-Schema as the preferred (but not exclusive) schema language.
3.	Reliance on Standards. The two approaches take a different view to standards adoption.  The current proposal reuses DSMLv2 extensively both in terms of schema and philosophy.  The alternative proposal relies on XML/Web Services standards such as WSDL, XML-Schema and XPath.
Object Models
Current SPML
The current SPML object model focuses on a set of operations which are closely related to the corresponding DSMLv2 operations.  The data transferred in these messages consists primarily of sets of attributes which in turn may contain sets of values.  Search requests use DSMLv2 filters directly and modifications are also expressed using DSMLv2 modification types.  The proposal also includes an extension mechanism in the form of extended requests which have associated metadata descriptors.

Alternative Proposal
The alternative proposal attempts to model the participants and object types identified in the PSTC use cases and provisioning systems in general.  At the center of this model is the “subscription” which represents the state of a provisioned target instance including any parameters required, as defined in the target schema.  The subscription may also contain the current state, and there is the ability to express the lifecycle of the subscription as a set of state changes.  The ProvisioningTarget class is a direct reflection of the PST identified in the use cases.  The target provides access to a schema element which can use any XML-based schema representation with XML-Schema being the schema language of choice.

Advantages of the Current Object Model
•	Familiarity.  Directories are common and expertise is widespread.
•	The reuse of DSMLv2 is held as an advantage. 
Advantages of the Alternative Object Model
•	Presents a model that relates more closely to the domain.
•	The ability to pass arbitrary data types as target parameters.
Points of Note in the Discussion
Those in favor of the current proposal cite the reuse of the DSMLv2 schema as an important advantage.  This, it was argued, gives the approach more chance of success since DSMLv2 is known to work and directories have been used extensively by provisioning vendors.  Adoption, it was claimed, is also more likely because of this.  It was also argued that by putting concepts such as state and lifecycle into the model, the model becomes restrictive.

For the alternative approach, the principal argument was that provisioning is not necessarily a directory problem and that directory protocols have been used out of necessity rather than suitability.  In defining a new standard, it was argued, we should target the domain, modeling the entities and concepts that provisioning systems use.  A directory based interface also imposes restrictions such as limited data types that should be addressed by a new specification.  The adoption argument was countered with the suggestion that, if SPML is almost the same as DSMLv2, there is no compelling reason to adopt it in favor of DSMLv2.  
Schema Representation
Current SPML
The current schema description mechanism is again based on LDAP/DSML concepts.  The central schema element is the ObjectClassDefinition which in turn points to a set of attribute definitions which provide a simple description of the allowed attributes for the class.  Although derived from directory concepts, this schema description language is SPML-specific and uses an XML representation.

Alternative Proposal
The alternative approach allows the target schema to be expressed using XML-Schema or another XML-based schema language, such as Relax NG.  XML-Schema is the schema language of choice though because of its popularity and the availability of a wide range of tools.  XML-Schema is also frequently used in conjunction with WSDL to describe service interfaces. 
Advantages of the Current Approach
•	Familiar model for those accustomed to directories.
Advantages of the Alternative Approach
•	The availability of tools that can understand and manipulate the schema.
•	The richness of XML-Schema allows complex types and relationships, enumerations, cardinality, data formats etc. to be expressed.
•	The ability to encapsulate schemas published by other Web Services, which would be reasonable targets for a provisioning system.
•	The ability to use the best schema language for any given situation and adapt to evolution in the field of XML schema languages and tools. 
Points of Note in the Discussion
More expressive schema has apparently been on the radar of the PSTC for some time but is difficult to accommodate in conjunction with an attribute/value data model.  During the discussion, and as part of the example implementation of the Tiny Telecom scenario, Jeff suggested that the current SPML schema language could be extended to allow the use of XML-Schema constructs to accommodate enumerations and string formats.  This was not pursued beyond a simple example.  This would not extend to the use of XML-Schema to describe complex types or other facets such as cardinality because of the impact that would have on the rest of the proposal.
Operation Comparison
The operations implemented in both approaches are very similar due to the fact that the use cases satisfied by both are the same.  The messages are very different however.  The following sections highlight the significant differences between each approach based on the generic operations, add, modify, delete and search which correspond roughly to the common use cases defined in the use case document.
The operations defined by the current proposal are included in the core schema and have been described already.  The alternative proposal splits the interface into a ProvisioningServicePoint (PSP) interface: 

and a query interface which consists of ProvisioningTargetQuery and ProvisioningSubscriptionQuery:

These interfaces are specified in WSDL.
Add, Use Cases 1, 2, 5, 6, 7, 9, 10
The simple example scenario called for the provisioning of an account.  This corresponds to an addRequest message in the current scenario and a createSubscription message in the alternative proposal.  In both cases there was a request for the target’s schema before the operation to create the account.  
For comparison, the current SPML example for adding a friends and family account including two contacts would look something like:

      <addRequest requestID="WT400956.4">
        <identifier type="urn:oasis:names:tc:SPML:1.0:core#GUID">
          <id>123X785Q.4</id>
        </identifier>
        <attributes xmlns="urn:oasis:names:tc:SPML:1:0:core">
          <attr name="objectclass" xmlns="urn:oasis:names:tc:DSML:2:0:core">
            <value>FriendsAndFamiliyAccount</value>
          </attr>          
          <attr name="contacts" xmlns="urn:oasis:names:tc:DSML:2:0:core">
            <value>584D268K</value>
            <value>345H789S</value>
          </attr>
        </attributes>
      </addRequest>

In this case the contacts are referenced rather than embedded because the current SPML supports only attributes and values which cannot be complex types.  In the alternative proposal, the friends and family account includes the contact information in the createSubscription request:

  <ProvisioningServiceSubscription>
    <identifier name="WT400956.3"/>
    <target>
<identifier name="friends_and_family_service"/>
    </target>
    <parameters>
<FriendsAndFamilyAccount xmlns="http://www.tiny.com/schema/friendsAndFamily">
  <contacts>
     <Contact>
       <firstname>Milly</firstname>
       <lastname>Ledbetter</lastname>
       <nickname>Mom</nickname>
       <phone>(323)555-1234</phone>
     </Contact>
     <Contact>
       <firstname>Silly</firstname>
       <lastname>Ledbetter</lastname>
       <nickname>Bro</nickname>
       <phone>(213)621-1234</phone>
     </Contact>
   </contacts>
 </FriendsAndFamilyAccount>
     </parameters>
  </ProvisioningServiceSubscription>

Modify, Use Cases 3, 8, 11
The scenario did not call for a modify operation.  This was addressed after the fact because of concerns raised about the ability to modify individual items in the complex data sets supported by the alternative proposal.  The alternative was modified to include modification operations very similar to those found in DSML, but using XPath to identify the items to be modified.  
There is an ongoing debate about the ability to unambiguously identify target data items using XPath.  Since the alternative proposal does not place any restrictions on the target schema, the target does not have to specify a unique identifier for data items.  This, it is argued, makes modifications difficult because target data may be changed by multiple clients, and that includes any attributes used for identification.  The counter argument is that in practical systems there would be a way to identify data items, and that the target schema should not be restricted by the specification.
Delete, Use Cases 4, 12, 19
Both approaches support delete by identity.
Search, Use Cases 14, 16, 18
The current SPML uses DSML search filters, allows the user to specify the set of attributes to return, and passes results back in a single message.  The alternative proposes the use of XPath as a query filter language, does not have the ability to specify individual data attributes, but does have an iterator mechanism to allow for the traversal of any arbitrarily large result set.
Asynchronous Operations, Use Case 13
Both models support asynchronous operations, allowing a client to poll for the status of a previous request.
Extended Operations
The current proposal explicitly defines extended operations in the schema.  This is comparable with the use of extended operations in LDAP/DSML.  In the alternative proposal, there is no attempt to make this part of the core model.  Instead the argument has been that users should take advantage of WSDL and other web services technologies to overlay any new operations on the provisioning service. 
Practical Considerations
Scalability
The ability to traverse large data sets on a search is an important scalability consideration.  This could be added to the current SPML using the LDAP paged control, which would in turn require controls in the specification.  The alternative proposal includes an iterator mechanism to accommodate this.  In terms of network overhead there seems to be no distinguishable differences between the two approaches.
Internationalization
The existing proposal is limited in its use of human-readable messages.  The alternative approach allows the use of language attributes for all messages, accommodating multiple locales.
Implementation Effort
This is very hard to estimate. On the one hand, there is wide experience with directory-type server and client implementation.  On the other, Web Services are becoming rapidly accepted and have a broad range of tools that simplify the creation of both clients and servers. 
Tools
The availability of a large number of tools that can manipulate XML-Schema, WSDL and XPath is seen as an advantage in the alternative proposal. Since target schema will usually be expressed using XML-Schema, these tools can be used with target schema also, which is not possible with the SPML-specific schema description language in the current proposal.  Since WSDL is central to the alternative approach, there is also an argument that tools may be used to generate client libraries directly from published provisioning systems.