Paul Sangree writes:
>Actually since the operator="replace" is on the <user> element, I think at
>most one <user> would be replaced.
But which user? In picking one, you've implied knowledge
about the identifying nature of the <name> element.
>(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.
The code on the device parsing the xml _has_ to know which
elements are identifiers. This data isn't opaque to the device.
>(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,
The management tool has to take one of two positions. It can either
understand the nature of the data that it's manipulating, implying
that understands the nature of the identifying elements; or it can
be generic, in which case it should learn the identifying elements
from the meta-data (the schema) not from the data itself.
>(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.
Supporting lookups using non-identifying elements (well, non-natively
identifying elements) can be expensive. The lookup mechanism as
spec'd is not that generic. The device (via the schema) can say
what the identifier are and limit lookups to just those elements.
>One partial solution that comes to mind is to put a key="key" attribute on
>each element to be used as a selection key.
Yup, this is the mechanism that I was referring to that we used in
junoscript (junos:key="key"), but it was whacked because it seemed
confuse some developers (who thought they could add the junos:key
element to anything and make it an identifier) and because it's a
bit unseemly to mix data and metadata. It was turned off by default
starting in junos-5.6.
Thanks,
Phil