[provision] The modification problem gets worse...

[Jeff Bohren <jbohren@opennetwork.com>]

 

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