Re: sub-tree filtering proposals

[Frank Strauß <strauss@ibr.cs.tu-bs.de>]

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.

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.



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