Maybe I missed the answer to this in one of the other posts, but if you no longer use the junos:key="key" to identify the lookup keys then how does the user know what attributes are indices? XML Schema does not provide a mechanism to identify them.
Thanks, /gww
> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Monday, August 25, 2003 21:34
> To: Paul Sangree
> Cc: netconf@ops.ietf.org
> Subject: Re: merge/replace selection criteria
>
> 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
>
> --
> 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/>