Re: Is DOM vs SAX a red herring?

[Larry Menten <lmenten@lucent.com>]

Keith,

To represent the transaction in multiple parts the target has to be
identified.
We have used XPath expressions for this purpose as in the following
example:

<transaction id="29">
        <deleteRequest opId="2"
select="/root/configuration/protocol/ospf/area[@id='0']" />
        <deleteRequest opId="1"
select="/root/configuration/protocol/ospf/area[@id='3']" />
        <addRequest opId="3"
select="/root/configuration/protocol/ospf">
            <area id="4">
                <interface id="ge-2/2">
                    <authentication-key>
                        <keyname>gargoyle</keyname>
                        <key-id>3</key-id>
                    </authentication-key>
                    <metric>1</metric>
                    <hello-interval>10</hello-interval>
                    <dead-interval>40</dead-interval>
                  
 <retransmit-interval>10</retransmit-interval>
                    <transit-delay>5</transit-delay>
                </interface>
            </area>
        </addRequest>
        <addRequest opId="4"
select="/root/configuration/protocol/ospf/area[@id='2']/interface[@id='ge-1/5']">
            <dead-interval>40</dead-interval>
        </addRequest>
        <addRequest opId="5"
select="/root/configuration/protocol/is-is">
            <area id="5"></area>
        </addRequest>
        <addRequest opId="6"
select="/root/configuration/protocol/ospf/area[@id='1']">
            <label-switched-path id="to-SFO">
                <metric>15</metric>
            </label-switched-path>
        </addRequest>
        <replaceRequest opId="7"
select="/root/configuration/protocol/ospf/area[@id='6']/label-switched-path[@id='to-SFO']">
            <metric>20</metric>
        </replaceRequest>
    </transaction>

Larry


Allen, Keith wrote:

All,

 

The modeling discussions that have been going on here lately have been interesting, and I don't necessarily want to stop them.  I think they are indicative of the kind of heavy work that needs to be done.  However, I do think they are largely outside the charter of this group, which was going to focus on the protocol used to operate upon an XML configuration model.

 

I thought Larry raised an interesting point with his proposal to include an "op" attribute in the information model elements with values like "overwrite" or "insert," but I am a little troubled by the mixing of protocol operation data with the information model.  For example, if you did a dump of an XML configuration file, these attributes would not make sense.  I'm not saying that I couldn't be convinced of their necessity, just that I am uneasy.  I was thinking, therefore, of alternatives that would meet Larry's goal of not having to send separate protocol messages to combine inserts and overwrites.  I do think it is important that the protocol flexibly support the ability to invoke multiple or complicated changes with a single operation.  How about something like the following:

 

<edit-config>

            <operation-group order="sequential">

                        <operation type="insert>

                                    ...xml snippet to be inserted in config...

                        </operation>

                        <operation type="overwrite">

                                    ... xml snippet to be overwritten...

                        </operation>

            </operation-group>

</edit-config>

 

This shows individual operations, which can have different semantics - insert or overwrite (is there anything else).  Also, the operations can be grouped together and ordered sequentially or any order.

 

 

Keith Allen

SBC Technology Resources

9505 Arboretum Blvd.

Austin,TX 78759

(512) 372-5741

kallen@tri.sbc.com

 

<transaction id="29">
        <deleteRequest opId="2"
select="/root/configuration/protocol/ospf/area[@id='0']" />
        <deleteRequest opId="1"
select="/root/configuration/protocol/ospf/area[@id='3']" />
        <addRequest opId="3"
select="/root/configuration/protocol/ospf">
            <area id="4">
                <interface id="ge-2/2">
                    <authentication-key>
                        <keyname>gargoyle</keyname>
                        <key-id>3</key-id>
                    </authentication-key>
                    <metric>1</metric>
                    <hello-interval>10</hello-interval>
                    <dead-interval>40</dead-interval>
                  
 <retransmit-interval>10</retransmit-interval>
                    <transit-delay>5</transit-delay>
                </interface>
            </area>
        </addRequest>
        <addRequest opId="4"
select="/root/configuration/protocol/ospf/area[@id='2']/interface[@id='ge-1/5']">
            <dead-interval>40</dead-interval>
        </addRequest>
        <addRequest opId="5"
select="/root/configuration/protocol/is-is">
            <area id="5"></area>
        </addRequest>
        <addRequest opId="6"
select="/root/configuration/protocol/ospf/area[@id='1']">
            <label-switched-path id="to-SFO">
                <metric>15</metric>
            </label-switched-path>
        </addRequest>
        <replaceRequest opId="7"
select="/root/configuration/protocol/ospf/area[@id='6']/label-switched-path[@id='to-SFO']">
            <metric>20</metric>
        </replaceRequest>
    </transaction>

Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA