[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]