[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM
Gerry, I agree that we should be willing to consider all options for SPML 2.0. I would be willing to consider just about anything including a total rewrite if that is what is required to meet the requirements for 2.0. But I am not going to support a total rewrite if the requirements can be met with an approach that is backwards comatible with the current spec. Of course we have not finalized the requirements so that decision can not be made yet. At highest level the SPML 1.0 spec is based around the concept that the provisioning data is represented as a collection of attribute/values rather than arbitrary XML. This is the approach taken by SAML as well as SPML. It is also the approach taken by many of the currently provisioning products in the market place. Many workflow, EAI, and BPA products use this approach as well. And of course it is also how all directory, meta-directory, and virtual-directory products work. Given that, I don't think it is reasonable to characterize that approach as "crippled" or "worthless". My suggested compromise for SPML 2.0 is that the provisioning data be represented as a collection of attribute/values plus arbitrary XML where appropriate. Under this approach provisioning target developers are free to use as much as needed from either model. People who already have provisioning targets (as we do) don't have to be impacted. This approach is not perfect, as compromises seldom are. I have a hard time believing that not being able to represent provision schema solely through XSD means that the spec has to be rewritten. It seems that there should be a compromise somewhere in between. If not the one I am suggesting, then perhaps another one. Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Tue 12/2/2003 6:21 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM Jeff, You know the history of this debate as well as I do, including the rush to demo at Catalyst in the face of the strenuous objections of both ourselves and Microsoft. Now you are using exactly the same arguments as you used then. We have committed to try to work with the committee as part of the SPML 2.0 effort but if we are not to debate the merits of different approaches now then there is no debate. I'd like to point out too that a radical departure from an earlier approach is not unprecedented - an example close to your heart would be the fact that DSMLv2 is obviously a far cry from DSMLv1. I'm not saying that WS-Provisioning does not require that a client retrieve the schema. What I'm saying is that it doesn't get in the way by imposing a proprietary schema language. If you are using XML Schema then you get XML Schema, not XML Schema shoehorned into another schema language. In terms of the respect that SPML 1.0 deserves, in my book that's something that results from being tested and implemented and found to be thorough, robust and appropriate. As you know we will not be implementing it. In terms of the utility that it represents, in any large scale application, which the interop demo was not, the limitations of the spec are crippling. It's encouraging to see that you recognize that there is merely "some" level of interoparability because to claim interoperability for a demo in a highly controlled environment with 10 simple attributes would be overstating the case. If the committee is to try to build a provisioning standard rather than another directory protocol, then it should not be built on the SPML 1.0 schema language, simple as that. If you are prepared to commit wholeheartedly to the use of XML Schema then let's dispense with the SPML schema language altogether. Sure, make it backward compatible but with SPML 2.0 as a superset, not as a dependant specification. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 12/02/2003 12:30 | | | PM | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >------------------------------------------------------------------------------------------------------------------------------| Gerry, I will try to flesh out the examples more in the next iteration of the OpenNetwork proposal. I should hopefully have that done soon. I agree with you about the SPML Identifier. In retrospect a pure urn based approach would have served better. I would like to make that change in SPML 2.0 so as to allow for either the current identifier approach or a URN approach. You seem to be implying that in WS-Provisioning an XSD based tool could somehow use the provisioning target schema definition to do something useful. The WS-Provisioning approach requires that the client queries the service to get the provisioning schema, and parses the result. For instance if you wanted to automatically generate client code then you would have to create a WS-Provisioning specific tool to do it. This is true with both proposals. Now whether SPML 1.0 had compelling features that make it worth being backwards compatible with is certainly a matter of opinion. From our standpoint it is compelling for many reasons, not the least of which is the fact that it is part of our currently shipping product. I suspect that is the case with some other TC members. From a OASIS TC standpoint it is compelling in that there is a published spec, and we should respect it as much as possible. Additionally the spec has been demonstrated to have some level of interoperability. This should not be a debate about which approach is superior. I would have had no problem with using any number of different approaches, had they been put forth earlier in the process. The question should be what is going to move the industry forward to adopting a provisioning standard. I can't see how issuing a completely different spec is going to accomplish that. If the SPML 2.0 spec is a complete rewrite of the 1.0 spec, why would anyone adopt it? What confidence would they have that SPML 3.0 would not come out and be totally different from 2.0? Jeff Bohren Product Architect OpenNetwork Technologies, Inc Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval. -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Tuesday, December 02, 2003 2:16 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM Jeff, I have to admit that I only glanced at your submission, assuming it was the same approach you had propsed on the list some time ago. Looking at it now, it does indeed offer a lot of benefits over SPML 1.0. It appears to be incomplete though and I'd like to see a more thorough example if you have one. For example, I'd like to see how something like the Liberty profile schema is imported, more information on the "name" attribute in your search request would be useful ("CommonName\cn" looks strange to me). I'm also not sure that I understand the object reference example. It would be useful to see the modified SPML core schema for this so that I can understand exactly how it would work. Of course, I still have an issue with the SPML-specific schema language. You know my complaints: - The language is incompatible with Web Services tools, or XML tools for that matter - XML Spy won't generate a sample SPML document for you as an example, off-the-shelf schema compilers such as Castor won't recognize it. - The approach flies in the face of accepted Web Services practices and the use of SPML schema essentially gets in the way of the XML Schema. If a user is to describe their data in XML Schema, what's the point of SPML schema? - The identifier mechanisms are clumsy and is much better handled using standard XML namespaces and URIs. - The schema language is still directory-oriented and is not an XML schema language. This is true also of DSMLv1 of course but it introduces difficulties when dealing with XML. For example, in your object reference example (and as I said I may not understand this properly), you define: ... <attributeDefinition name="role" type="urn:oasis:names:tc:SPML:1:1#Identifier"/> ... <objectClassDefinition name = "role"> <memberAttributes> <attributeDefinitionReference name = "cn" required = "true" /> <attributeDefinitionReference name = "description" /> <attributeDefinitionReference name = "password" /> </memberAttributes> </objectClassDefinition> ... The problem here of course is that the "type" of the role attribute is not a role but an "identifier". This is handled much better in XML schema languages that have strong typing and relate closely to their resultant XML representation. If backward compatibility is an issue, and I'm not sure how much of a problem it could be at this point, then consider that the WS-Provisioning proposal can easily transport SPML 1.0 schema and data. To me, this approach offers a number of benefits including the tool compatibility and Web Services emphasis that SPML lacks. As an example of how an SPML1.0 schema might be expressed in WS-Provisioning: <wsp:ProvisioningTarget xmlns:wsp="urn:ibm:names:ws:provisioning:0.1:core"> <wsp:identifier name="xyz123"/> <wsp:schema> <spml:schema xmlns:spml="urn:oasis:names:tc:SPML:1:0" xmlns:dsml="urn:oasis:names:tc:DSML:2:0:core"> <spml:providerIdentifier providerIDType = "urn:oasis:names:tc:SPML:1:0#URN"> <spml:providerID>urn:oasis:names:tc:SPML</spml:providerID> </spml:providerIdentifier> <spml:schemaIdentifier schemaIDType = "urn:oasis:names:tc:SPML:1:0#GenericString"> <spml:schemaID>standard</spml:schemaID> </spml:schemaIdentifier> <spml:attributeDefinition name="objectclass"/> <spml:attributeDefinition name="cn"/> <spml:attributeDefinition name="uid"/> ... <spml:objectClassDefinition name="person"> <spml:memberAttributes> <spml:attributeDefinitionReference name="objectclass" required="true"/> <spml:attributeDefinitionReference name="cn" required="true"/> <spml:attributeDefinitionReference name="uid"/> ... </spml:memberAttributes> </spml:objectClassDefinition> </spml:schema> </wsp:schema> </wsp:ProvisioningTarget> If the SPML 1.0 had many compelling features that we could not afford to lose then tacking on support for XML Schema and XML data would be a worthwhile exercise. However, this is not really the case and the retrofitting is going to result in a cumbersome specification that will be difficult to understand and implement. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 12/02/2003 07:27 | | | AM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, I have already proposed an enhancment to SPML to allow for arbitrary XML to be used as provisioning data (see the OpenNetwork proposal for more details). This requires no encodings or transformations and allows XSD to be used to define the structure of the XML data. This also has the advantage of being fully backwards compatible with SPML 1.0. Why does this not meet your requirements for the transport of XML data? Jeff Bohren Product Architect OpenNetwork Technologies, Inc Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval. -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Tuesday, December 02, 2003 1:35 AM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM Jeff, I think you might not be remembering our original proposal correctly. We have always advocated the use of a target object to hold schema. I plucked the following segment from an e-mail in the list archives dated February 28th of this year: ... <complexType name="ProvisioningTargetSchema"> <sequence> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <element name="ProvisioningTarget"> <complexType name="ProvisioningTargetType"> <sequence> <element name="identifier" type="tns:ProvisioningIdentifier" minOccurs="1" maxOccurs="1"/> <element name="schema" type="tns:ProvisioningTargetSchema" minOccurs="0" maxOccurs="1"/> </sequence> </complexType> </element> ... You'll find this almost verbatim in our submission. It was never a suggested that the target schema had to be embedded in WSDL. As far as the portions of the SPML that should be kept, as I said earlier, and as you well know, our problems go to the heart of the spec. The SPML-specific schema language is unsatisfactory for a number of reasons that we've discussed at length already. The schema then dictates the data model - that XML-unfriendly attribute-value data model that we have also discussed at length already. The schema and data model then impact the operational interface. I don't want to suggest that we at an impasse but I do think that any proposals based on the SPML schema language will not come close to satisfying our requirements. The SPML must allow the use of XML Schema as the target schema language, at a minimum. Not as a tacked on band-aid but as a first-class schema language. It must also provide for the transport of XML data as XML data - no wierd transformations or encodings. The reasons for these requirements are obvious and particularly imperative in a Web Services context. Fixing these demands a major overhaul of SPML 1.0. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 12/01/2003 05:47 | | | PM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, It would be helpful to make a proposal of what parts of the current SPML 1.0 specification should be kept as is and what should be replaced or modified. That way we can have a useful discussion on the mail list leading up to the next face to face. For instance you originally insisted that the only acceptable way to represent the meta-data of the provisioning target (i.e. the provisioning schema) was to represent it in XML Schema in WSDL so that client could be auto-generated. Now in your WS-Provisioning submission that approach is not taken. Instead the client gets the schema using a "FetchTargetRequest", and processes the "FetchTargetResponse" in order to read the schema. Since you have already abandoned a pure WSDL approach for representing schema, why could that not be merged into the current SPML schema mechanism? Jeff Bohren OpenNetwork Technologies -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Mon 12/1/2003 4:42 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM I think it's fair to say that the submission is intended to act as a statement of direction, indicating the form that we would like to see the SPML take. We've been quite clear about the fundamental problems that we have with the current approach and on many occasions have pointed out that these issues need to be addressed at the foundations of the SPML. Reconciling the SPML1.0's schema and data models with the direction detailed in our submission is not trivial. It is certainly not a cut-and-paste exercise. The question to me is what portions of the SPML can be retained to meet our needs. At present those are few. |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 11/25/2003 06:56 | | | AM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Discussion and analysis of SPML 2.0 submission from IBM | >----------------------------------------------------------------------- -------------------------------------------------------| The IBM Proposal looks to be a very good specification on it's own merits, but has no compatiblity with the current SPML 1.0 specification. What exactly is IBM proposing? Is IBM proposing the the current SPML specification be wholesale replaced with the IBM proposed specification? Or is IBM proposing this as input into the SPML 2.0 specification? If IBM is proposing this as input rather than a wholesale replacement, what parts does IBM feel are appropriate to incorporate into the SPML 2.0? Jeff Bohren Product Architect OpenNetwork Technologies, Inc Try the industry's only 100% .NET-enabled identity management software. Download your free copy of Universal IdP Standard Edition today. Go to www.opennetwork.com/eval. -----Original Message----- From: Darran Rolls [mailto:Darran.Rolls@waveset.com] Sent: Tuesday, November 25, 2003 9:46 AM To: provision@lists.oasis-open.org Subject: [provision] Discussion and analysis of SPML 2.0 submission from IBM As you are no doubt aware, IBM has submitted a specification document to the PSTC for consideration as content and requirements for SPML Version 2.0. This submission can be found at [1]. Do you have questions regarding the intent, status or content of this submission? [1] http://www.oasis-open.org/archives/provision/200310/msg00001.html To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor kgroup.php . To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]