Subject: RE: sub-tree filtering proposals

From: "Glenn Waters" <[email-masked]>
Date: Wed, 9 Jun 2004 12:31:11 -0400

> From: Andy Bierman [mailto:[email-masked]]
> Sent: Wednesday, June 09, 2004 11:42
> To: Frank Strauß
> Cc: [email-masked]
> Subject: Re: sub-tree filtering proposals
 
> IMO, we should do the following (yet another proposal :-)
> 
>   - mandatory-to-implement subtree node selection

Is the mandatory to implement based on what Jeurgen proposed?

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

It's not pointless. Some reasons that an XPath subset is useful are:
- compatability with full XPath which allows developers to learn one set of
filtering 
- code reuse between subset and full implementation
- training will be easier -- can leverage existing training for the bits we
support
- a clean migration path from "XPath-lite" to "XPath-full"

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

Regards, /gww

---

From: Phil Shafer <[email-masked]>
Date: Wed, 09 Jun 2004 12:59:06 -0400

"Glenn Waters" writes:
>- compatability with full XPath which allows developers to learn one
>set of filtering

... and then be fustrated when the full xpath doesn't work....

>- a clean migration path from "XPath-lite" to "XPath-full"

I don't see this happening.  If you start with a subset and
grow it over time, clients will never know what subset the
device supports and will break on devices that don't match
their requirements.  Given that high-end devices are likely
to just pick up a full implementation (libxml2), the subset
will be broken day one.  Even then, the ability of the
device to implement arbitrary bits of XPath logic and
expressions will be an immense and changing burden.  Unless
we're all switching over to XML databases on the device,
the act of doing something like:

   following-sibling::security-associations[preceding-sibling::sa-tunnel-information[1]/sa-tunnel-index=$xpath-tunnel-number]

won't be simple.

Thanks,
 Phil

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 09 Jun 2004 10:23:46 -0700

At 09:31 AM 6/9/2004, Glenn Waters wrote:

>> From: Andy Bierman [<mailto:[email-masked]>mailto:[email-masked]] 

this is the subtree filtering already in the draft and
documented in my original email on this thread.  This
is not partial Xpath

>- compatability with full XPath which allows developers to learn one set of filtering 
>- training will be easier -- can leverage existing training for the bits we support 

I think the WG is still split on this point.
I agree with Phil.  We will have a lot of variance
between minimal subset and full Xpath, and application
writers will have difficulty managing this variance.
If we had mandatory subtree plus optional full Xpath,
there is less variance possible (just 2 choices: full 
subtree, full Xpath).

Or we could make both filtering mechanisms optional and
let the market decide which ones are useful.  

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2004 19:48:30 +0200

> there is less variance possible (just 2 choices: full 

subtree filter + full XPATH = 2
XPATH subset   + full XPATH = 2

> let the market decide which ones are useful.  

The market will decide anyway. But making both filtering schemes
optional just means the mandatory is no filtering (kind of introducing
a third option and I bet this is what applications end up doing -
sucking the whole thing and running xslt (which uses xpath) locally.

I tend to agree with Phil that agreeing on a single approach would
indeed by the best approach. I probably differ with him (not sure 
though) that XPATH is the right way to go. Probably the solution
is indeed XPATH or no filtering at all.

/js

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 8 Jun 2004 10:53:49 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Glenn Waters" <[email-masked]>
> Cc: "Frank Strauß" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, June 09, 2004 10:23 AM
> Subject: RE: sub-tree filtering proposals
...
> documented in my original email on this thread.  This

I'm sorry to hear this.  Implementation and validation
would be easier if the mandatory-to-implement subtree
filtering were a strict subset of Xpath.  Implementations
with full Xpath support wouldn't need to do anything
special.

...
> there is less variance possible (just 2 choices: full
...

The variance is a problem only if we permit it to happen.
Even having two choices is not good, but if those happen
to be a well-specified strict subset and the whole enchilada,
I think it would be manageable.  Allowing various shades
of grey would not be.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2004 19:12:55 +0200

On Wed, Jun 09, 2004 at 12:59:06PM -0400, Phil Shafer wrote:

> [...] Given that high-end devices are likely
> expressions will be an immense and changing burden.

Please elaborate.

/js

---

From: Phil Shafer <[email-masked]>
Date: Wed, 09 Jun 2004 14:32:19 -0400

Here's a recent elaboration:

 >Message-Id: <[email-masked]>
 >To: [email-masked]
 >cc: Andy Bierman <[email-masked]>, [email-masked]
 >Subject: Re: Proposal to do away with netconf attributes in data model payloads 
 >In-Reply-To: Your message of "Thu, 08 Apr 2004 23:45:28 +0200."
 >             <[email-masked]> 
 >Date: Thu, 08 Apr 2004 18:33:00 -0400
 >From: Phil Shafer <[email-masked]>
 >
 >Juergen Schoenwaelder writes:
 >>> >I think all approaches require changes to <get-config> retrieved data 
 >>> >to compose a meaningful <edit-config> arguments.
 >
 >I think the only change required is to add the 'operation="replace"'
 >attribute to the top-level element of the configuration tree returned
 >from <get-config>.
 >
 >>I do fail to understand why creating something new for all netconf
 >>boxes instead of subsetting XPATH only for small devices will at 
 >>the end be a winning situation. 
 >
 >Subsetting will lead to differing subsets.  You won't know what you
 >can do until you know what implementation you're talking to.  Unless
 >you believe users will restrain themselves and stay within the
 >defined subset.  
 >
 >Your other mail asked about the cost of xpath and why it's easier to
 >parse elements than xpath expressions.  I don't think there's much
 >difference between parsing the following:
 >
 >
 >(a)
 >  set interfaces so-0/0/0 unit 0 family inet address 10.1.2.3/24
 >
 >(b)
 >  <configuration>
 >    <interfaces>
 >      <interface>
 >        <name>so-0/0/0</name>
 >        <unit>
 >          <name>0</name>
 >          <family>
 >            <inet>
 >              <address> <!-- adding a new one -->
 >                <name>10.1.2.3/24</name>
 >              </address>
 >            </inet>
 >          </family>
 >        </unit>
 >      </interface>
 >    </interfaces>
 >  </configuration>
 >
 >(c)
 >  interfaces/interface[name='so-0/0/0']/unit[name='0']/family/inet/address[name='10.1.2.3/24']
 >  <!-- where 'name' is the only element name supported inside a predicate -->
 >
 >But there is an order of mangnitude difference in handling:
 >
 >  interfaces/interface/unit/family/inet[starts-with(../../../name, 'so-') and string-length(../../name) = 1]/address[substring(name,3) != '/24' and (not(@inactive) or disable)]
 >
 >If I subset most of xpath out of netconf-xpath, why use it?  Just
 >because slashes are more stylish that xml elements?  If we're making
 >an xml api, it makes no sense to prefer strings to real xml.
 >
 >The element sub-tree is a good match between what the device can
 >do easily and what the app writer needs.
 >
 >Also worth noting that the use of xpath implies that the intermediate
 >nodes already exist, which isn't always the case.  In JUNOS, we
 >effectively remove empty levels from the database when an empty
 >level would be meaningless, so a <delete> could remove levels that
 >were not it's target and a <create> that is depending on the existence
 >of that level would fail.
 >
 >I'm looking to make an API that contains the abilities of the CLI
 >so that we can stamp out screen scraping,  not to create new
 >technology that can be implemented six months after the MIB is
 >implemented (and twelve months after the feature ships).
 >
 >Thanks,
 > Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 9 Jun 2004 21:19:20 +0200

>  >you believe users will restrain themselves and stay within the

Either the filter mechanism is standardized or not. I fail to see why 
an ad-hoc subtree filtering mechanism is any better or worse compared
to an XPATH subset as long as it is well defined and standardized. 

[ The rest of the quoted email does not seem to give any additional 
  insights why chosing a subset of xpath "will be an immense and 
  changing burden". Sorry if I missed the important piece. ]

/js