> -----Original Message-----
> From: Paul Sangree [mailto:psangree@cisco.com]
> Sent: Monday, August 25, 2003 4:18 PM
> To: Phil Shafer
> Cc: netconf@ops.ietf.org
> Subject: Re: merge/replace selection criteria
>
>
> >Another valid-but-wrong interpretation would be replacing all
> >users.
>
> Actually since the operator="replace" is on the <user> element, I think at
> most one <user> would be replaced.
>
> >The interpretation depends on the understanding of
> >identifiers (identifying elements), but how should this be
> >expressed inside the protocol? Or does it need to be, given
> >that code handling users will either know what the identifiers
> >are or learn them from the schema file?
>
> IMHO, the selection keys (i.e. identifiers) should be explicit rather than
> making any assumptions that the target system knows which elements are
> keys. There are several advantages to going this route:
> (1) The code that processes an edit-config operation can be generic for a
> given configuration document format. For example, the same code could
> edit
> any XML document.
> (2) The management tool that generates the edit-config request does not
> have to know which fields are valid keys, since any element or attribute
> can be used as a key,
> (3) Depending on the desired result, different fields can be used as
> keys. Referring to the user list example, either <address> or <name>
> could
> be used as the key depending on the requestor's intent.
>
> One partial solution that comes to mind is to put a key="key" attribute on
> each element to be used as a selection key. In the example below, the
> <name> element is marked as a key to indicate that only the <user> whose
> <name> is "Bill Baker" is to be replaced.
>
> <rpc message-id="12345" xmlns="http://ietf.org/xmlconf/1.0/base">
> <edit-config>
> <target>
> <running/>
> </target>
> <config xmlns="http://example.com/schema/userconf"
> xmlns:xc="http://ietf.org/xmlconf/1.0/base">
> <users>
> <user xc:operation="replace">
> <name key="key">Bill Baker</name>
> <address>123 A Street</address>
> </user>
> </users>
> </config>
> </edit-config>
>
This concept has worked well for Intelliden using Junoscript. It allows us to modify an object in the configuration without outputting all elements under the object.
> I say this is only a partial solution because it has some problems:
> (1) Only elements (not attributes) can be marked as keys,
> (2) It does not provide semantics to express "replace the <user> whose
> <name> is 'Bill Baker' with a <user> whose name is 'William Baker'".
>
>
> Paul Sangree
>
>
> --
> 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/
Brendan Kelly