Re: Issue 14.1: Retrieval Subset specification proposal

[Andy Bierman <abierman@cisco.com>]

At 04:10 AM 3/19/2004, Juergen Schoenwaelder wrote:
>On Thu, Mar 18, 2004 at 09:24:51AM -0800, Andy Bierman wrote:
>
>> >I tend to believe that both solutions (xpath and operation
>> >attributes in the data model) are kind of broken and just
>> >attempts to push away work that really needs to be handled
>> >and specified by the protocol verbs.
>> 
>> I disagree.  The problem we are trying to solve has already
>> been addressed by XPath.  We are trying to use existing
>> XML standards, not reinvent or create static subsets.
>> 
>> The filter cannot be a parameter in the protocol operation
>> RPC for the same reasons as the 'operation' attribute.
>> It has to be embedded in the data model.  So we need
>> another standard attribute (called xfilter?) supported
>> by the TBD data modeling language.
>> 
>> The #xfilter capability (was called #xpath) would indicate 
>> that the agent has the ability to support 'xfilter' attributes
>> for XPath selection in <get> and <get-config> operations.
>> Every data model definition will contain any XPath 
>> implementation and conformance requirements for that data model.
>> It is also data model specific whether the xfilter attribute
>> can be used within <edit-config> operations.
>> 
>> FYI:
>> 
>> XPath standard:
>> http://www.w3.org/TR/xpath
>> 
>> Basic XPath tutorial:
>> http://www.zvon.org/xxl/XPathTutorial/General/examples.html
>
>You missed the point of my question. Please tell me the reason
>why the filter cannot be a parameter in the protocol operation and
>the reason why the 'operation' attribute has to be in the payload.

Because it's possible (and useful) to include config data from
different data models in the same edit-config operations, and
different operation and XPath values will be relevant in 
each data model.  Also, one operation or filter parameter may
not apply to the entire payload.


>And please tell me the precise semantics of the <config/> parameter
>of get-config (and how that is going to be data model independent).

The <config> element is the container for the configuration
data payload, which may be any valid XML (not in the netconf:base-1.0
namespace).


>/js

Andy



>-- 
>Juergen Schoenwaelder               International University Bremen
><http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen, Germany 


--
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/>