I feel like we are trying to vote on a half solution. Without context of where XPath fits into the solution I find it hard to distinguish between options A-C.
I don't want option D as it mixes the protocol into the model.
As another poster on this list said, a concrete example might help direct people to the answers.
Regards, /gww
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Tuesday, March 30, 2004 17:35
> To: netconf@ops.ietf.org
> Subject: Poll for consensus on edit operations
>
> Hi,
>
> I'd like people to weigh in on the attribute vs. element
> issue, including the encoding details (see below).
>
> I now agree with Juergen that it is highly undesirable
> to require protocol-specific attributes in data-model
> elements to implement any NETCONF protocol operation.
> It is better to keep the data models as protocol independent
> as possible, to avoid dependencies on specialty tools
> that will limit the deployment of NETCONF. It is better
> to use more complex mechanisms (like XPath) that are likely
> be supported by general-purpose XML standards-based tools.
>
> thanks,
> Andy
>
> ----------------------------------------------------------------
>
> 1) Specifying the start point of the edit action
>
> If attributes are used, then the start-point is the
> element containing the attribute. If attributes are
> not used, then the start point has to be specified
> somehow. This can be done in a simple manner with
> the attribute (in the edit-action element) start-level="<N>"
> or the more complex start-path="<Xpath-expr>" attribute.
>
> 2) Basic form of the <edit-config> operation
>
> A) edit-actions are contained in <config>
>
> <edit-config>
> <target><running/></target>
> <test-option>test-then-set</test-option>
> <error-option>rollback-on-error</error-option>
> <config>
> <create>
> <foo> ... </foo>
> </create>
> <modify>
> <goo> ... </goo>
> </modify>
> </config>
> </edit-config>
>
> B) edit-actions are contained in <edit-config>
>
> <edit-config>
> <target><running/></target>
> <test-option>test-then-set</test-option>
> <error-option>rollback-on-error</error-option>
> <create>
> <foo> ... </foo>
> </create>
> <modify>
> <goo> ... </goo>
> </modify>
> </edit-config>
>
> C) multiple <config> sections allowed, each with a verb
> and a start-level; This avoids the need for Xpath
> support completely, since an action could appear
> more than once (<config> maxOccurs="unbounded")
>
> <edit-config>
> <target><running/></target>
> <test-option>test-then-set</test-option>
> <error-option>rollback-on-error</error-option>
> <config operation="create">
> <foo> ... </foo>
> </config>
> <config operation="modify">
> <goo> ... </goo>
> </modify>
> </edit-config>
>
> D) edit-actions as operation attributes (current approach)
>
> <edit-config>
> <target><running/></target>
> <test-option>test-then-set</test-option>
> <error-option>rollback-on-error</error-option>
> <config>
> <foo operation="create"> ... </foo>
> <goo operation="modify"> ... </goo>>
> </config>
> </edit-config>
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>