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