Re: sub-tree filtering proposals

[Andy Bierman <abierman@cisco.com>]

At 04:44 AM 6/9/2004, Frank Strauß wrote:
>Juergen Schoenwaelder wrote:
>
>> On Tue, Jun 08, 2004 at 12:36:23PM +0200, Frank Strau? wrote:
>> 
>>> > 
>>> > //interface[type="ethernet"][connector="present"]
>>> 
>>> This kind of operation first builds the set of all <interface>s which is
>>> then limited to those with type="ethernet" and this subset is then limited
>>> to those with connector="present". This means a sequence of predicates is
>>> not commutative, in contrast to the logical AND operator. An example where
>>> this would be signifcant is this:
>>> //interface[type="ethernet"][position()=last()] would address the last
>>> ethernet interface, while
>>> //interface[position()=last()][type="ethernet"] would address the last
>>> interface, if it is an ethernet interface, otherwise an empty node set.
>>> 
>>> Xpath predicates (the parts in brackets) may contain boolean operators
>>> ("expr1 and expr2","expr1 or expr2", "not(expr)").
>> 
>> True in general. 
>> 
>> However, the proposed required minimal subset does not include things 
>> like last() or position() - only simple comparisons of element/attribute
>> values (no other operators). Do you think the fact that sequences of 
>> predicates are not commutative is still important in this special 
>> restricted case?
>
>I'm sorry, I did not follow the discussion and reasoning on the proposed XPath
>subset. From the operator's point of view I would deeply regret if netconf
>would come up with such a derivation from the standard. It reminds me on a
>phrase from the (earlier) SMI specs: "...using an adapted subset..." which
>caused many misunderstandings in the past and made it impossible to use
>existing tool chains. I hope we have learned enough from those problems,
>especially since probably the most important advantage of XML based protocols
>is the ease of application and broad knowledge on its base specs.

Juergen is not proposing an adapted subset.  It is a pure subset.
The main argument for Xpath subset here is that it will be easier
to adapt existing tools than to build new ones from scratch.
Eventually, more platforms will be able to support full Xpath,
so the minimum subset may become a non-factor over time. 

Clearly, every NETCONF developer would need to know about the Xpath
subset.  Limiting usage to the NETCONF subset is not an issue 
for developers generating Xpath expressions themselves or writing
them manually.  If an NMS developer (using an application to generate
Xpath expressions) limits the selection criteria to the subset
that NETCONF supports, then what is the likelihood that the
application will generate expressions outside the subset?

Obviously, an application that supports full Xpath will be
capable of offering more sophisticated selection features
than NETCONF supports.  In theory, if the developer avoids
those features, the application should inter-operate with
the NETCONF agent.  In practice, it's not going to be this simple.


>In general, a service might (be required to) supply *more* than a standard, and
>a client implementation might make use of less than the standard. But if a
>service is allowed to support *less* than the standard, it is simply not
>supporting that standard and causes trouble to client implementors.
>
>To (kind of) answer the question: In order to (a) make the expressions look
>more like what people who are familiar with XPath would expect, and to (b)
>support also an "or" operator (and a "not" operator), I would prefer the
>notation with the according operators over the sequence of predicates. If only
>an "and" operator would be required, I wouldn't care, since it would not be
>XPath, anyway.

We do not have WG consensus that all devices can support,
and all applications need, full Xpath.  I think we have
consensus for a limited set of features:
  - select all nodes matching specified attribute or simple content values
  - select a specific instance of an object, in a manner independent
    of any instance naming scheme
  - select specific nodes by name
  - select by any combination of the above

This is the feature set we have been assuming via the subtree filtering
examples all along.  If some people think we need more powerful
selection criteria as the minimum feature set, then speak up.

Juergen's Xpath subset seems to be enough to support this feature set.
I think the subtree filtering supports it as well.

My biggest concern is that we forget that the target platforms
for NETCONF agent are embedded operating systems within network 
devices, and small devices don't need the same complex features 
that large devices may need.

IMO, we should do the following (yet another proposal :-)

  - mandatory-to-implement subtree node selection
  - optional-to-implement "full Xpath 1.0" node selection
    - #xpath capability set if this is supported

The XML Directorate consensus seems to be leaning to partial
Xpath, but there are strong concerns that an Xpath subset will be 
incompatible with standard tools, and therefore pointless.

The advantages of the proposal above are:
  - subtree filtering is easy to implement on agents;
    only XML parser needed, not XML and Xpath parsers
  - subtree expressions are valid XML which look identical
    to the data models (XML content) that operators will
    need to know anyways.  Xpath should not be mandatory-to-know
    in order to use NETCONF.
  - Vendors are encouraged to also support full Xpath 1.0, if it
    is appropriate for the platform and data model size
  - We avoid definition and deployment of a NETCONF-only Xpath subset

Andy


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