[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]