Hello,
Seems to me that XPath is just another way of specifying a component name (edit-path)
[and a not so simple one at that].
If the data model of the payload is to be deferred to the implementation, wouldn't
it be logical to do the same for the edit-path specification, for example;
<edit-config>
<target><running/></target>
<test-option>test-then-set</test-option>
<error-option>rollback-on-error</error-option>
<create>
<edit-path ...namespace stuff...> ... </edit-path>
<config ...namespace stuff...>
...data...
</config>
</create>
<modify>
<edit-path ...namespace stuff...> ... </edit-path>
<config ...namespace stuff...>
...data...
<config>
</modify>
...
</edit-config>
This way, one could use an XPath _expression_, a component name, whatever...
Maybe we need to define a type element or attribute to make that clear;
<edit-path type="xpath">...xpath _expression_...</edit-path>
or <edit-path><xpath>...xpath _expression_...</xpath></edit-path>
vs
<edit-path><text>...comp id or something...</text><edit-path>
The payload (note that I moved the <config> block inside to wrap the payload,
that could be something else, I'm just using it to structure the two arguments to the
operation) can also take the different forms as modeled by the device (e.g. flat or
hierarchi).
If the data-model is not going to be standardized, then I see no help in
standardizing the naming.
If, on the other hand, there is a wish out there to formalize/standardize the model
or its structure at large then XPath might need to be required.
In an abstract way, I see as possible operations;
operation: add or create
parameters: where (the target component/element)
what (the data to add)
operation: modify or set
parameters: where (the target component/element)
what (the new data)
operation: delete
parameter: where (the target component/element)
operation: merge (netconf until recently minus the embedded operation attributes
i.e. always additive)
parameter: what (the new data)
map "where" to <edit-path> and "what" to <config> and you have it.
Conceptually, the "where" above does not identify an "element" within the
payload but the element in the target object model where the operation is to
occur.
Thanks
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Wednesday, March 31, 2004 3:20 PM
To: Randy Presuhn
Cc: netconf@ops.ietf.org
Subject: Re: Proposal to do away with netconf attributes in data model payloads
At 11:08 AM 3/31/2004, Randy Presuhn wrote:
>Hi -
>
>> From: "Glenn Waters" <gww@nortelnetworks.com>
>> To: "Randy Presuhn" <randy_presuhn@mindspring.com>;
>> <netconf@ops.ietf.org>
>> Sent: Wednesday, March 31, 2004 10:46 AM
>> Subject: RE: Proposal to do away with netconf attributes in data model payloads
>...
>> > We need to be *very* careful here. If it is possible to construct
>> > multiple names for a single object instance, the handling of
>> > relationships (and comparing
>> > configurations to determine whether they are equivalent) gets ugly fast.
>>
>> I agree. XML Schema does not have the concept of unique key or such.
>> As part of the data modeling discussion we need to discuss how or if
>> we mark attributes as keys (and they must be retrievable, unlike
>> SNMP!)
>>
>> The way XPath is defined there is no requirement to have unique keys.
>> You specify one or more attributes to search on and you get back the
>> set of matching objects (it's actually a bit more complex than what I
>> just described but conceptually what I described is somewhat
>> accurate).
>>
>> So if we choose XPath then we may have to subset the features we
>> support to fit the network management requirements that we have.
>
>I don't think subsetting XPath would be necessary. We just need to be
>sure that there is a way to determine a "canonical" name of an object
>instance. There will be a multitude of XPATH expressions that might
>find that object instance (perhaps even independent of its name), but,
>regardless of how we've found it, we need to be able to determine what
>its name is.
I guess we're going to be choosing the lesser of two evils.
Now you've slid completely down the slope such that full
XPath support would be required for every netconf agent implementation, and we have to fully specify the naming scheme of the TBD data modeling language before we can finish the protocol.
I would rather have option (D) -- leave the operation
attribute in the spec -- than go this route. From
an implementation POV, having the operation attribute within the element whose callback function needs to know the operation is easy to implement on the agent. It may be easier on the application than Xpath as well.
For a real world example, it would be nice if someone
wants to model a simple chassis -- a container with N
slots. Each slot has a 'ports' container with M physical ports, where M can be different for each value of N. The homework assignment is to show the assumed data model and Xpath _expression_ for selecting the start-point of an edit operation. (E.g., set the duplex-mode on slot 3, port 7.)
Andy
>...
>> > and still begs the question about which normalization form is in
>> > use. I think this has to be nailed down at the protocol level.
>>
>> I don't know what normalization form means in the context of this
>> work. Can you explain.
>...
>
>See the big NOTE in the XPATH specification section 3.6.
>(http://www.w3.org/TR/xpath#strings) for a good explanation.
>
>Randy
--
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/>