[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [provision] Proposal comparisons...
Gerry, Let's start with the contact list from the original Tiny Telecom example. You can't identify the contact with out checking for the unique combination of first name, last name, and middle initial. What if two contacts had the same first name, last name, and middle initial? This is a very likely scenario among cousins of many cultures. This is, after all, a friends and family account. Since the contact list display the exact same problem I am talking about, you have not shown an example where this issues is NOT a problem. I am not so much worried about the obvious cases like the contact list. I am more concerned about this creeping into provisioning systems in ways that the implementers are unaware of. As the provisioning data representation becomes more complex, and as more clients access a service, the more likely this kind of problem is. This also brings up the interesting questions of what should happen when the XPath on a modify request points to more than one element. Should it be an error? Should all the elements be modified? The first element? The last element? Should the RA specify the behavior? Should the service specify the behavior? Is the element cardinality defined in the schema enforced on the data passed to modify requests? Is it enforced on the results of the modifications? If not enforced on the results of the modification, is it enforced on the resulting search responses? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Sunday, March 16, 2003 11:38 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: RE: [provision] Proposal comparisons... Jeff, I don't think you've shown it to be unreliable, you are arguing that it is unreliable. What you are arguing here is that changing an identifier changes identity. That's fair, but you are again assuming that the only way to identify a data item is by using all of its state. My argument is that in any practical target that is not true and if it were it would be up to the target to change its schema. The central issue here is that I do not wish to place restrictions on the target schema. Show me a practical case where you think this is an issue and we can discuss it. Or, we could just ask any committee members who feel that they have come across target where this would be an issue to weigh in. Gerry |---------+----------------------------> | | "Jeff Bohren" | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/16/2003 06:04 | | | PM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: Gearard Woods/Irvine/IBM@IBMUS | | cc: <provision@lists.oasis-open.org> | | Subject: RE: [provision] Proposal comparisons... | | | >----------------------------------------------------------------------- -------------------------------------------------------| Gerry, This does not address my concerns at all. All you have done is put in the schema the approach that I have already shown to be unreliable. If you want to address my concerns, tell me how your proposed solution would solve the following situation: Start with the initial data: <A> <B> <C>foo1</C> <C>foo2</C> <C>foo3</C> </B> <B> <C>foo1</C> <C>foo5</C> <C>foo2</C> <B> </A> RA1 and RA2 read the data. RA2 changes the 2nd C in the first B to bar1. Now the data looks like: <A> <B> <C>foo1</C> <C>bar1</C> <C>foo3</C> </B> <B> <C>foo1</C> <C>foo5</C> <C>foo2</C> <B> </A> Now RA1 wants to delete the first B. How does RA1 delete the first B, where B was defined by foo1, foo2, foo3; but is now foo1, bar1, foo3? Jeff B. -----Original Message----- From: Gearard Woods [mailto:gewoods@us.ibm.com] Sent: Fri 3/14/2003 9:41 PM To: Jeff Bohren Cc: provision@lists.oasis-open.org Subject: Re: [provision] Proposal comparisons... Jeff To address your concerns about modifcations, I've worked up yet another package. This does not include a revised scenario but just a revised schema to include the ability to specify modifications with a level of detail comparable to the current SPML proposal. The revised schema uses XPath to identify the items to be modified, as we have been discussing. Gerry (See attached file: scenario.zip) |---------+----------------------------> | | Jeff Bohren | | | <jbohren@opennetw| | | ork.com> | | | | | | 03/13/2003 08:03 | | | PM | | | | |---------+----------------------------> >----------------------------------------------------------------------- -------------------------------------------------------| | | | To: provision@lists.oasis-open.org | | cc: | | Subject: [provision] Proposal comparisons... | | | >----------------------------------------------------------------------- -------------------------------------------------------| I am still not satisfied that we understand enough about how the GW proposal would implement modifications in order to make a proper decisions. But I understand we need to close this one way or the other on Monday, so attached is my summary of how the two approaches compare. I will be out of the office on Fri, and will be unable to discuss these issues further until Mon. Jeff Bohren OpenNetwork Technologies #### Proposal_Evaluation_01.doc has been removed from this note on March 14, 2003 by Gearard Woods ---------------------------------------------------------------- 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]