[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Is DOM vs SAX a red herring?



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