[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Fw: SPML Roadmap
---- Start SpamAssassin results 7.20 points, 7 required; * 1.2 -- BODY: Message is 0% to 10% HTML * 6.0 -- RAW: Message text disguised using base-64 encoding ---- End of SpamAssassin results
- From: Gearard Woods <gewoods@us.ibm.com>
- To: "Elron, Rami" <rami_elron@bmc.com>
- Date: Wed, 30 Jul 2003 15:48:54 -0700
Rami, Sorry for the delay in getting back to you, I've had some problems accessing the list. I'm not sure what you mean by your answer to the third point. The ability to modify specific portions of a value is not supported by the SPML, no matter what type or scope you define. There are other more serious problems with what you are sugesting in any case. The most significant is the ability to search across the values contained in an XML attribute value. For example, in your previous example how would I express a request to search for everyone who lives in Austin? Your suggestion that XML data be transported in base64 encoded form is indicitive of the problems associated with this approach. What you are suggesting could be compared to a database vendor demanding that every data item be held in a BLOB. As the customer I'm complaining that I need to be able to modify specific portions of the BLOB and search using values contained within the BLOB. In fact, I'm wondering what purpose a database system serves if it prohibits searches and modifications of my data? I cannot just accept your assertion that this can be done without specific details of what the requests and data would look like, particularly when the specification doesn't support it. I agree that the SPML should be able to accommodate other schema languages but there are ways to solve that problem while maintaining the consistency of the XML. Unfortunately, as I've said before, the current SPML makes this very difficult if not impossible. As for proposing an alternative, you may recall that the committee voted against an alternative, presented in an attempt to address these problems, earlier this year. At this point I think it is the responsibility of the PSTC members who are in favour of the current approach to demonstrate how even the trivial aspects of interoperability in an XML/Web Services environment can be supported. Once we are all clear on the severity and extent of the weaknesses of the current approach then we can proceed with remedies. Until then however, I think any attempt to introduce alternatives will only be a distraction. Gerry |---------+----------------------------> | | "Elron, Rami" | | | <rami_elron@bmc.c| | | om> | | | | | | 07/28/2003 02:47 | | | AM | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: "Cohen, Doron" <Doron_Cohen@bmc.com>, provision@lists.oasis-open.org, "Elron, Rami" <rami_elron@bmc.com> | | Subject: RE: [provision] Fw: SPML Roadmap | >------------------------------------------------------------------------------------------------------------------------------| Gerry, My previous note illustrated how the SPML current model might accommodate a complex structure. This note attempts to address your remarks with regard to that approach. SPML is an evolving standard that currently supports a core set of capabilities, which serves versatile customer needs. The SPML specification is undergoing a process that will endow it with powerful capabilities based on the current spec and the roadmap. In light of the benefits such an approach offers – the overhead you mentioned with regard to parsing is in my opinion justified. In any case, I do not consider parsing to be an obstacle, particularly if it is based on a clear and firm set of rules. The capability of a standard to be somehow agnostic with respect to data structure scheme is on the other hand an incredible asset. With regard to the first point in your letter, my first note suggested to use elements such as <properties> to further define and scope types, requiring a modest effort from the PSTC to define appropriate attribute names to support them. The following illustrates how the <properties> element might be used to refer to a specific type. In the example, two attribute/value pairs refer to the specific schema file and type definition, respectively, and additional pairs may be used to provide more pertinent information should such a requirement come up. This example should be regarded as a suggested approach, not necessarily a full-blown, syntactically proof solution. The issue discussed is not addressed by the current SPML specification per se, and there are various alternative paths that address the same requirement and should clearly be discussed and examined by the committee. … <objectClassDefinition name="Residence"> <superiorClasses> <objectClassDefinitionReference name="Complex"> <schemaIdentifier schemaIDType="urn:oasis:names:tc:SPML:1:0#GenericString"> <schemaID>[reference to schema file, e.g. to xsd file] </schemaID> </schemaIdentifier> <properties> <attr name="SchemaType"> <value>[PSTC-set ID for specific data format, e.g. ‘XMLSchema’] </value> </attr> <attr name="ObjectType"> <value>residence</value> </attr> … </properties> </objectClassDefinitionReference> </superiorClasses> </objectClassDefinition> … Note: The objectClassDefinitionReference chosen name attribute (e.g. “Complex”) is required to be a reserved keyword. The choices for schemaIDType and schemaID depend on the relevant reference to an XMLSchema, and may be set by the committee as well. The properties' SchemaType and ObjectType attribute names should also be reserved keywords. As for the 2nd point. I believe that there are several possible ways to transport the attribute value – including pulling the XML content out of the container (and replacing it with a link), or encoding the value. The definition of DSML attribute values permits the following types: UTF-8, base64Binary, and any URI. Using Base64 to encode the XML in <value> seems to be a valid option. Base64 is a very common encoding and does not pose a considerable overhead in terms of performance. XML Data can be represented as Base64 and while this requires conversions at both ends and results in a 33% larger data size, it is simple to implement. In addition, there are public domain utilities/classes providing fast Base64 encoding and decoding. As for the 3rd point, one can make the requested modification – and not necessarily by replacing the whole attribute value. It will depend on the scope/type defined and referenced. The prospect of decoupling the schema from data structure presentation format is a compelling argument in favor of the approach demonstrated herein. While the importance of XML Schema is evident there are other data description languages/conventions (not necessarily XML-based), which currently, and may also in the future enjoy support from various parties. In my opinion, any proposal for SPML should be able to accommodate various alternatives and not be orbiting around XML Schema-like options alone. I truly hope that there is a way to fuse the benefits of both approaches – yours and that of the current SPML specification, in a way that will satisfy all parties and meet the requirements of all customers. That said, the SPML specification and roadmap documents present appealing concepts that deserve to be seriously considered as well. In order to make real progress with regard to this ongoing discussion, I believe that the committee needs to be presented with a full-fledged alternative or modification proposal, and have that proposal evaluated subject to our concerns as well. It will be both imperative and interesting to see how any alternative supports the non-trivial aspects presented in the SPML specification AND roadmap documents, and how it supports the needs experienced by vendors and customers planning to implement SPML soon. 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 8:25 PM To: Elron, Rami Cc: Cohen, Doron; provision@lists.oasis-open.org; Elron, Rami Subject: RE: [provision] Fw: SPML Roadmap Rami, I don't think that what you are suggesting is practical within the context of the current SPML. Here's a few of the reasons why: 1. You still have not identified which schema element in the referenced schema represents your type - a schema document may contain many type definitions. 2. XML Schema instance documents cannot be transported in a DSML attribute value as you have shown because DSML attribute values may only be strings which precludes the use of raw XML. You would instead have to escape it so your example: ... <attribute name="XMLData"> <value> <simplepersonprofile xmlns:xsi="http://www.vocoder.org/XMLSchema"> <firstname>Mr</firstname> <lastname>Wakeman</lastname> <residence> <address>6th street</address> <city>Austin</city> <country>Texas</country> <state>United States</state> </residence> <jobhistory> <title>marketing manager</title> <date>January 2002</quantity> <manager>Dan Becker</price> <description>Let’s party</price> </jobhistory> </simplepersonprofile > </value> </attribute> ... Now becomes: ... <attribute name="XMLData"> <value> <simplepersonprofile xmlns:xsi="http://www.vocoder.org/XMLSchema"> <firstname>Mr</firstname> <lastname>Wakeman</lastname> <residence> <address>6th street</address> <city>Austin</city> <country>Texas</country> <state>United States</state> </residence> <jobhistory> <title>marketing manager</title> <date>January 2002</quantity> <manager>Dan Becker</price> <description>Let’s party</price> </jobhistory> </simplepersonprofile > </value> </attribute> ... This is more than a simple aesthetic problem. For one, you have introduced the overhead of encoding and decoding what could turn out to be a large document. Secondly, the receiver of this document, because the content is no longer XML, must perform an additional parse operation. Also, because the profile is no longer an XML document, it cannot be processed by common XML processing tools such as XSLT. And I'm sure I've overlooked other difficulties. 3. How do I go about changing Mr Wakeman's residence? The answer of course is that I cannot because I must replace the whole attribute value. May I suggest that if the SPML is to use XML Schema then we consider what it would take to offer full support for it and for other XML-based schema languages. In my view, this is not something that can just be bolted on as an afterthought. Gerry |---------+----------------------------> | | "Elron, Rami" | | | <rami_elron@bmc.c| | | om> | | | | | | 07/24/2003 08:25 | | | AM | |---------+----------------------------> >--------------------------------------------------------------------------- ---------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: provision@lists.oasis-open.org, "Elron, Rami" <rami_elron@bmc.com>, "Cohen, Doron" <Doron_Cohen@bmc.com> | | 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 has been removed from this note on July 24, 2003 by Gearard Woods #### Response to SPML roadmap concerns - part 3.doc has been removed from this note on July 28, 2003 by Gearard Woods
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]