[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] The modification problem gets worse...
Gerry, The only way for modifications to work in your proposal is if there is a way to properly identify data elements even as they be changed. Again I will point out that your example only works if two different RAs do not try to update the same contact or contact list. If they do, there is likely to be data corruption simply because there is no immutable identifier. Yes, you could have put one in your example, but the very fact that you did not indicates that it is not the type of thing that that provisioning service developers will think of first. This scenario was created by you and reviewed by others, and yet you still put in data elements that could not be safely modified. Why do you think all the rest of the developers will easily figure this out? This flaw is obvious even in the most simply scenario. If it fails in a simple scenario, it can never work reliably in a complex one. There is only one solution that will reliably support modifications. That is, every element and sub element for which modifications can be applied must have a immutable identifier attribute on it. That will allow for modifications to be supported correctly, but diminishes the advantages of the entire original approach. As for supporting complex data types in SPML, they must be created as independent entries, which is how this problem is solved in SPML, DSML, and LDAP. That limitation is exactly why SPML, DSML, and LDAP do not have the flaw that your proposal does. All entries have immutable identifiers (or at least immutable until explicity renamed) by design. This is both a limitation and an advantage. Jeff Bohren -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Sun 3/16/2003 9:40 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] The modification problem gets worse... Jeff, Welcome back. Obviously, in the sample scenario it would have been trivial if I had resorted to simple identifiers, as you did, rather then embedding the data for the contacts in the request. In that case I would do as you would and simply use the identifer when deleting the contact. Since the data in my example is complex, something that I don't think you can accomodate at all, I'm saying that in practice there would some way to identify the item to modify unambiguously. In the tiny telecom example, to remove Milly from the contact list the modify request would simply identify her by name, (perhaps something like //Contact[firstname="Milly" and lastname="Ledbetter"]). If she was not found in the list then that fact would be reported to the client. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/16/2003 05:55 | | | PM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] The modification problem gets worse... | | | >------------------------------------------------------------------------------------------------------------------------------| Gerry, In the Tine Telecom example the only way to uniquely identify the a contact is by an and clause of all the contact info. As I have pointed out this is inherently unreliable. If contact changes by even a single letter in one of the components it is no longer identifiable as the contact that it was. Just to be clear on this, in the Tiny Telecom example there is just one, and only one way to uniquely identify a contact, and it requires that the all the components of the contact remain fixed from the time an RA reads the information to the time and RA tries to update it. Does this count as one of the "vast majority of cases". Jeff B. -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Fri 3/14/2003 1:19 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] The modification problem gets worse... Jeff is out of town today but my response to this point is that I'm not suggesting that a key be required. It seems more likely to me that for the vast majority of targets, the user would have a way to identify the item that they wished to modify. The point is that XPath offers the ability to identify the items of interest in multiple ways, one of which is sure to be suitable. In Jeff's absence, does anyone have a comment on this? Steve? Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/13/2003 06:16 | | | PM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: provision@lists.oasis-open.org | | Subject: RE: [provision] The modification problem gets worse... | | | >------------------------------------------------------------------------------------------------------------------------------| Gerry, You have the problem right, but absolute positioning will not help. Again, it is the same problem. Because other clients can add and delete elements, you can't count on the position to identify the element you want to delete. You can't count on the contents of the elements, because they may have changed. An immutable identifier is a solution as you noted, but more than that it is probably the only reasonable solution. But does this solution fit with the original intent of yourproposal? The advantage supposed to be allowing the provisioning data to be open ended and defined as anything that could be defined using XML Schema. If the only way to support modifications is to restrict the provisioning data to having an immutable key for every element, is the original premise of the proposal valid any more? This is exactly what I meant when I said that the modification problem may not be solvable under the intent of the original proposal. Also, if you require that every element have a immutable key, then you are now very close the how data is structured in LDAP. So why not go with SPML as it is now? Jeff Bohren -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thu 3/13/2003 4:30 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] The modification problem gets worse... Jeff, I think XPath is expressive enough to handle this situation without requiring that the contact (B?) still contain all of the same data. My last example obviously was an add. For a delete of a single B element, I think you could approach it in a number of ways: - Positionally, as in /A/B[0] - to remove the first B component in A. - By value oviously, as in /A/B[C=foo1 or C=foo2 or C=foo3]. If you were afraid that one of the values might have changed. - By using some immutable value as a key, as you might a DN component: /A/B[key=value] Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/13/2003 12:27 | | | PM | | | | |---------+----------------------------> >------------------------------------------------------------------------------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] The modification problem gets worse... | | | >------------------------------------------------------------------------------------------------------------------------------| Gerry, No need to apologize. But I believe that the problems involved with modifications may be insurmountable given the original intent of your proposal. Yes you can replace an entire list. But as we have seen from the previous thread, that will not work in general. You need to be able to add elements to and delete elements from a list. Delete can only be done if you can identify the element to delete. That can not be done because the elements themselves could have sub-elements that may have been modified by another RA. Please look again at my original example and show me how this could be handled in your proposal: Suppose a record has data that looks like: <A> <B> <C>foo1</C> <C>foo2</C> <C>foo3</C> </B> <B> <C>foo4</C> <C>foo5</C> <C>foo6</C> <B> </A> No suppose RA1 wants to change the first B component. It would have to issues a modification request with an XPath that refers to B where B has foo1, foo2, and foo3. Now suppose the modification changes the record so that it looks like: <A> <B> <C>foo1</C> <C>bar8</C> <C>foo3</C> </B> <B> <C>foo4</C> <C>foo5</C> <C>foo6</C> <B> </A> Now suppose at a later time RA2 wants to remove the first B component from A. It would have to issues a modification request with an XPath that refers to B where B has foo1, foo2, and foo3. This request would now fail. There is no automatic way for RA2 to reconcile the differences. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thursday, March 13, 2003 2:36 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] The modification problem gets worse... Jeff, I've apologized to Steve for my knee-jerk reaction already. Let me offer you the same apology. I agree that you gain a measure of confidence through the use of an existing standard, I'm not really arguing that point. What I'm arguing is the appropriateness of the specification that you elect to use and I submit that if it doesn't fit then you should start afresh. I never imagined that after two weeks there would be no outstanding issues with a new approach. As you point out, my example is not fully formed and I have not claimed that it is. What I am claiming is that none of these issues, Search, Modify, or others that you will undoubtedly discover, are insurmountable. What I'm proposing is that we examine what we really want from this specification. I regret that we have not been present in the committee for the past six months to pit proposals side-by-side on the same timeline but have to resort to an accelerated debate, outside of any real process. I still think the exercise is useful though, and if you are game then I'd like to continue to pursue it and leave any resolution to our conversation on Monday. Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/13/2003 11:06 | | | AM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: provision@lists.oasis-open.org | | Subject: RE: [provision] The modification problem gets worse... | | | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, You are incorrect about how DSML Modifications work. They do support deleting value from an attribute, as well as adding a value to an attribute. Even if delete was not supported (which it is), I could still show a similar example of two different RAs adding a value to the same attribute. Again, it works in the current specification, and does not work in your proposal. What you are illustrating quite well is the benefit of basing a new protocol on work done in another one. We don't have to scratch our heads and wonder how the protocol should behave. We have RFCs, books, user communities, and vendor support to turn to for questions. I made this point early in the discussion that we can be confident that the current spec will work because we based it on another spec that is known to work. We start over from scratch and we lose that. This also illustrates the importance of examining other protocols that are similar to what you are proposing. I think that the problems that have arising originally around searching and now around modifications illustrate the need to look at like protocols for validation that the approach is sound and that it is likely to be adopted by the industry. Unfortunately I am at loss as to what protocols we could compare it to. Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thursday, March 13, 2003 1:24 PM To: Steve Anderson Cc: Jeff Bohren; provision@lists.oasis-open.org Subject: RE: [provision] The modification problem gets worse... Steve, Thanks for all the help. All kidding aside, there is no ability to delete specific values in the current SPML, it uses DSML modifications which only allow for attributes to be deleted, added or replaced in total. My scenario still holds because you will not get the "value not found" or "value already exists" errors that you are relying on. Gerry |---------+----------------------------> | | "Steve Anderson" | | | <sanderson@openne| | | twork.com> | | | | | | 03/13/2003 10:17 | | | AM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS, "Jeff Bohren" <jbohren@opennetwork.com> | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] The modification problem gets worse... | | | >----------------------------------------------------------------------- -------------------------------------------------------| I've been following this thread, and it think Gerry's example here actually illustrates Jeff's point. I'll take a stab at explaining ... In Gerry's example, after initial creation, two different RA's want to change Item B. The first, RA1, wants to replace both 'values' (3,4) with two new values (5,6). The second RA, RA2, only wants to replace value 4 with value 5. RA1 executes first, followed by RA2. In Gerry's example, it appears that the modifications can only be done by supplying the whole set (3,5), so the resultant set is just that -- (3,5). The problem is that value 6 has been inadvertently replaced with value 3. In Jeff's approach, the RA2 can perform the following: - Modify B: remove value 4 - result: Value not found -- interpreted by RA2 to be fine, since this is the desired result anyway - Modify B: add value 5 - result: Value already exists -- interpreted by RA2 to be fine, since this is the desired result anyway The final value set for B is (5,6). No corruption. Hope this helps. -- Steve -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Thursday, March 13, 2003 12:56 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: Re: [provision] The modification problem gets worse... Jeff, Your argument here and in your previous message is predicated on the assumption that the RAs in my scenario hold the state of the data while in yours they do not. In yours they simply request a modification that is independent of the current state of the data. You argue that this is not a race condition problem and that your scenario will not suffer from it. Let's go through it again using your implementation: RA 1 Entry RA2 create A: 1,2 B: 3,4 read A:1,2 B:3,4 replace B: 5,6 A:1,2 B:5,6 replace B:3,5 A:1,2 B:3,5 This is how the current specification works and according to you this is fine. I'm not sure that I see much of a difference in the end result. Please explain. Gerry |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/13/2003 05:22 | | | AM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: provision@lists.oasis-open.org | | cc: | | Subject: [provision] The modification problem gets worse... | | | >----------------------------------------------------------------------- -------------------------------------------------------| In a previous posting I have shown how the current proposal by Gerry Woods will cause data corruption when doing modifications. I have shown this using a very simple case. Gerry has suggested that this could be overcome by a modification mechanism that uses XPath in combination with ldap like modification semantics. Although this alternative has not been fully fleshed out, it will not work either. Even theoretically it will fail. Let me explain why. Suppose a record has data that looks like: <A> <B> <C>foo1</C> <C>foo2</C> <C>foo3</C> </B> <B> <C>foo4</C> <C>foo5</C> <C>foo6</C> <B> </A> No suppose RA1 wants to change the first B component. It would have to issues a modification request with an XPath that refers to B where B has foo1, foo2, and foo3. Now suppose the modification changes the record so that it looks like: <A> <B> <C>foo1</C> <C>bar8</C> <C>foo3</C> </B> <B> <C>foo4</C> <C>foo5</C> <C>foo6</C> <B> </A> Now suppose at a later time RA2 wants to remove the first B component from A. It would have to issues a modification request with an XPath that refers to B where B has foo1, foo2, and foo3. This request would now fail. There is no automatic way for RA2 to reconcile the differences. Jeff Bohren Product Architect OpenNetwork Technologies, Inc ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]