Re: sub-tree filtering proposals

[Andy Bierman <abierman@cisco.com>]

At 10:32 PM 6/3/2004, Wes Hardaker wrote:
>>>>>> On Fri, 4 Jun 2004 00:45:15 +0200, Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de> said:
>
>Juergen> You do not want to subset XPATH to reduce the implementation
>Juergen> costs and at the same time you propose a different filter
>Juergen> mechanism to reduce the implementation cost (which at the end
>Juergen> might map to a subset of XPATH).
>
>Juergen has a perfect point here.  You're creating something new,

I'm documenting something that has been in the spec since
it was called XMLCONF.  

>which will take new code to implement something that doesn't yet exist
>because you don't want to use something else which is potentially more
>complex but yet code exists for it. 

I am extremely confident that implementation of this
subtree filtering will take less code space and dev-effort
than a full Xpath implementation.

You can't just point to the equivalent Xpath for subtree filters
and ignore the rest of the Xpath feature set.  

> Don't you think it will take
>significantly less work for implementations to implement partial XPath

Repetition is the key to learning...
There will be no NETCONF standard subset of Xpath.
Compare subtree to full Xpath implementation only.
The WG already decided that implementation of full Xpath 
for NETCONF conformance is not appropriate for most devices,
and will not be required.

>for which there is a plethora of pre-existing code than it will be to
>implement (and get right) something entirely new?  The whole point
>behind using XML in the first place for this initiative was to make
>use of existing tools, but yet for this one you're throwing out the
>existing tools and libraries. Seems odd. 

See the previous thread on Xpath, especially Phil's "closing
arguments".  IMO, we would keep NETCONF out of most network
devices for years because the agent implementation cost and
runtime resource requirements would be too high.

What is it about subtree filtering that is so hard to implement?
Clearly, all existing embedded implementations can handle
containment nodes and leaf nodes with simple content.  There
are implementations from multiple vendors of all of these
features because they are simple and intuitive:
   -- retrieve only the subtrees that exactly match the 
      criteria presented in the search
   -- return a subtree starting at an empty leaf node (e.g. <users/>)

These are the fundamental filter operations that we need
for NETCONF.  IMO, Xpath is overkill for these fundamental
needs.  


>-- 
>"In the bathtub of history the truth is harder to hold than the soap,
> and much more difficult to find."  -- Terry Pratchett 

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