[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Fw: SPML Roadmap
Gerry, The attached document includes some examples that elaborate on my previous note. Best regards, Rami. --------- Rami Elron Senior System Architect Security Business Unit BMC Software Ltd. Tel: 972 3 766 2434 Fax: 972 3 645 1100 Mobile: 972 64 286 434 email: rami_elron@bmc.com -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thursday, July 24, 2003 2:00 AM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Fw: SPML Roadmap Not to be picky, but which venues would those be? I can't imagine that what you are proposing emerged from any previous discussion as an ideal solution, particularly in a world where we are no longer constrained by an attribute/value model. I also don't understand why you are assuming that this is only relevant to accounts. I'm suggesting this scenario because of the schema used at the interop where a very simple set of user information was provisioned. Based on that, I thought it would be instructive if a more real-world example was examined and so I suggested the Liberty user profile. Let's talk about containment. LDAP/DSMLv2/SPML support containment, or the illusion of containment, through the use of a hierarchical naming system. Without using such a hierarchical naming system how do I express the kind of containment that you are demanding? Let's paraphrase your solution in pseudo-SPML: <batchRequest> <addRequest> <identifier type="urn:oasis:names:tc:SPML:1:0#LibertyUniqueID"> <<< ???? What goes here???? >>> </identifier> <attributes> <attribute name="objectclass"> <value>IDPPType</value> </attribute> <attribute name="InformalName"> <value>Johnny</value> </attribute> </attributes> </addRequest> <addRequest> <identifier type="urn:oasis:names:tc:SPML:1:0#LibertyUniqueID"> <<< ???? What goes here???? >>> </identifier> <attributes> <attribute name="objectclass"> <value>CommonNameType</value> </attribute> <attribute name="CN"> <value>John Smith</value> </attribute> </attributes> </addRequest> <addRequest> <identifier type="urn:oasis:names:tc:SPML:1:0#LibertyUniqueID"> <<< ???? What goes here???? >>> </identifier> <attribute name="objectclass"> <value>AnalyzedNameType</value> </attribute> <attribute name="PersonalTitle"> <value>Sir</value> </attribute> <attribute name="nameScheme"> <value>urn:x:y:z:1.0</value> </attribute> </attributes> </addRequest> ... </batchRequest> There are all kinds of other issues with this including the fact that there can be any number of levels in this hierarchy, each one requiring an add, but importantly: 1. The relationships here are those that you outlined: the IDPPType instance has a common name which in turn has an analyzed name. What identifiers do I use to indicate containment? Am I forced to use DNs or some other hierarchical naming system? 2. If the identifiers are not used to express containment, how do I associate them? 3. How do I describe or impose the constraint that there may only be 10 informal names for example? 4. How do I convert back and forth between the instances described in XML Schema and those described in SPML schema? It seems that now there is a requirement that I maintain state and mapping information for each profile and any constituent objects. I'm effectively forced to maintain two data models and map between them outside the service that is using the actual data. 5. You have indicated that, for the schema mapping, there is an implicit set of rules. Contained types that are primitives, such as a string, become SPML attribute types, while those that have a cardinality are contained. What about XML Schema attribute definitions such as nameScheme? How do convert those and how do I distinguish between attributes and elements in an SPML add request, for example, when doing conversions to/from the real profile? Where did these schema mapping rules come from and is there, or will there be, a normative set? Not to mention that now I have to send something resembling what I just outlined, and suffer through all kinds of compromises and conversions, to communicate: ... <InformalName>Johnny</InformalName> <CommonName> <CN>John Smith</CN> <AnalyzedName nameScheme="urn:x:y:z:1.0"> <PersonalTitle>Sir</PersonalTitle> </AnalyzedName> </CommonName> ... Your dismissive tone here is frustrating not only because you seem to be avoiding getting into any real depth on this issue and appear to be minimizing what is a very real problem, but also because you are implying that this concern is due to ignorance of some previous discussions in some other venue, that incidentally cannot be mentioned. In actual fact an attribute/value model is an extreme compromise. So, rather than dismissing the question, if you could provide actual XML, or update what I've presented here, or indeed provide a real example of one of the other "several ways to do the same thing" and then allow open and full discussion of the issues and compromises then I think we could start making progress, one way or the other. By the way, I'd still like to know if Rami's suggestion is true. Is the PSTC going to allow XML Schema to be referenced? If this is true then the data and operation model will not hold and it seems to me that the approach so far will require significant rework. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 07/23/2003 02:01 | | | PM | |---------+----------------------------> >--------------------------------------------------------------------------- ---------------------------------------------------| | | | To: <provision@lists.oasis-open.org> | | cc: | | Subject: RE: [provision] Fw: SPML Roadmap | >--------------------------------------------------------------------------- ---------------------------------------------------| As Rami notes there are several ways to solve the issue representing of complex data types represented in a hierarchical attribute/multi-values data model. These issues have been so thoroughly discussed in other venues that I won't repeated them here. SPML is not limited to managing accounts. It can also be used to manage other types of objects such as groups, organizations, etc. It can also be used to manage objects that are contained by other objects, which is one way to represent complex data types. One approach that would work for the Liberty Personal Identity Profile would be to represent the core profile in one object and then have contained objects for each of the complex data types. For instance there would be an InformalName attribute on the profile object but the list of CommonName objects would be represented as contained instances of a common name object. Likewise the common name object would have a CN attribute but the list of AnnalyzedName objects would represented as contained instances of analyzed named objects. You could then create, modify, or delete all of the relavent objects in a single SPML Batch Request. Again there are several ways to do the same thing. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wednesday, July 23, 2003 4:10 PM To: provision@lists.oasis-open.org Subject: [provision] Fw: SPML Roadmap ----- Forwarded by Gearard Woods/Irvine/IBM on 07/23/2003 01:10 PM ----- |---------+----------------------------> | | Gearard Woods | | | | | | 07/23/2003 10:48 | | | AM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: "Elron, Rami" <rami_elron@bmc.com> | | cc: provision@lists.oasis-open.org, "Elron, Rami" <rami_elron@bmc.com> | | From: Gearard Woods/Irvine/IBM@IBMUS | | Subject: RE: SPML Roadmap (Document link: Gearard Woods) | >----------------------------------------------------------------------- -------------------------------------------------------| Rami, Thanks for the document. I'm afraid that it doesn't address my concerns though and I think you might be underestimating the coupling between the schema and the data model. If you are suggesting that an XML Schema document could be referenced by an SPML schema, then the SPML is obliged to allow instances of structures defined in that schema to be transported. Let's remain with the Liberty user profile and get very specific about what the schema would look like and how the schema impacts the data model. To extend your example, I imagine that you are suggesting that the Liberty schema be referenced like this: <schema> <objectClassDefinition name="LibertyPersonalProfile"> <superiorClasses> <objectClassDefinitionReference name="Complex"> <schemaIdentifier schemaIDType="urn:oasis:names:tc:SPML:1:0#GenericString"> <schemaID>http://www.projectliberty.org/specs/lib-svc-id-pp.xsd</schemaI D> </schemaIdentifier> </objectClassDefinitionReference> </superiorClasses> </objectClassDefinition> </schema> This raises a number of questions: 1. How is the element inside the schema document identified? I'm interested only in the IDPP element. I disagree with the suggestion that specific names be reserved by the way, this seems cumbersome and esentially turns the name into something else. 2. Imagining that I do identify the portion of the schema that I'm interested in, how do I use it? In your document you say that "While the definition may seem to imply reliance on a simple attribute/value model, it can actually leverage this very model to take advantage of much more complex data structures." If this is true, what would the add request look like based on the external schema? What about a modify request? These both require an attribute/value model so I'm having some difficulty understanding how the XML Schema would relate to the actual request data. If you could show me specifically what the request XML would look like in both cases I'd be obliged. 3. If the SPML really can actually consume XML Schema, why define a separate, SPML-specific, schema language? Gerry |---------+----------------------------> | | "Elron, Rami" | | | <rami_elron@bmc.c| | | om> | | | | | | 07/23/2003 08:51 | | | AM | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS, provision@lists.oasis-open.org | | cc: "Elron, Rami" <rami_elron@bmc.com> | | Subject: RE: SPML Roadmap | >----------------------------------------------------------------------- -------------------------------------------------------| Hi Gerry, The attached document addresses and hopefully answers your concerns. If you have any further questions or remarks regarding this document or the roadmap document, please do not hesitate to call me. Best regards, Rami. ------------------------------------------------------------------------ ---- --------- Rami Elron Senior System Architect Security Business Unit BMC Software Ltd. Tel: 972 3 766 2434 Fax: 972 3 645 1100 Mobile: 972 64 286 434 email: rami_elron@bmc.com -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Wednesday, July 23, 2003 12:22 AM To: rami_elron@bmc.com; provision@lists.oasis-open.org Subject: SPML Roadmap Rami, Further to the call yesterday, I wanted to clarify one of the major problems that I have with the SPML as it stands and to get your feedback on how the problem might be solved either with today's approach or with features that are on the roadmap. Fundamentally, I believe that the schema language introduced by the current SPML is too restrictive and reflects a data model that will not be able to satisfy my immediate needs to transport complex XML data. In fact, I have difficulty seeing how a roadmap built on this schema language can be made to fit my requirements in the long run. As an example, could you explain to me how I might use the SPML in the simple scenario where I have a service (a Web Service) that I wish to provision which requires the user information to be provided using the Liberty Alliance user profile (http://www.projectliberty.org/specs/lib-svc-id-pp.xsd)? This is not an outlandish scenario by any means, and you could substitute other user representations such the ebXML UserType for example. Obviously, since the SPML cannot support XML Schema, I have to think that publishing the schema for such a service might be problematic. It also seems difficult, given the attribute/value data model in the current SPML, to communicate an instance of one of these structures. If you can reassure me that this is in fact quite seamless and simple in the current SPML, or your roadmap answers this concern, I would be very grateful. Thanks, Gerry #### Response to SPML Roadmap concerns.doc has been removed from this note on July 23, 2003 by Gearard Woods You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_wor kgroup.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro up.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/provision/members/leave_workgro up.php
Response to SPML Roadmap concerns - more.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]