[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sub-tree filtering proposals
On Wed, Jun 09, 2004 at 01:44:30PM +0200, Frank Strau? wrote:
> 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.
First, I believe a subset of XPATH (not an adapted subset) is still better
than something homegrown. (The most vocal members of the WG do not seem
to buy full XPATH as a requirement.) Personally, I believe that the
operators using netconf will ask for full XPATH anyway, so the subset
requirement will likely not be a real issue in practice.
> 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.
I think the general idea is that boxes announce whether they do support full
XPATH or just a reduced subset. I do not see that there is anything wrong
with this.
The alternative, a home grow filter format which implementations are
required to support, seems worse to me. Bottom line is that either
(a) the netconf WG makes a decision to require XPATH full stop, or
(b) the WG makes a decision to support XPATH and require a subset of it, or
(c) the WG makes a decision to support XPATH and to require another
home-grown filter format.
Since (a) does not seem to be getting WG concensus, I believe (b) is the
best we can do.
> 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.
Point taken. I can live either way. I just do not want to see (c)
happen.
/js
--
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/>