Subject: subtree filtering: content match nodes

From: Andy Bierman <[email-masked]>
Date: Sun, 20 May 2007 16:41:09 -0700

Hi,

I just read sec. 6.2.5 again in RFC 4741, and found yet another 'concern'
with subtree filtering.

The text in the 2nd sentence explicitly states  wrt/ to
a content match node:  "it represents an exact-match filter".

I cannot find any text anywhere that mentions canonical data formats,
or schema data type conversion.  It is extremely likely that an
agent implementation will need to convert between a numeric data type
and a string representation of that data type to support this feature.

For interoperability, we should have a precise meaning of 'exact match'.

Does 'exact match' mean that the agent MUST NOT convert the
filter value to any schema-defined data type (i.e., convert number
to canonical and/or internal format, or adjust string whitespace or
convert character entities)?

Instead, the agent must compare a string representation of the internal
value to the exact filter string value.

Or is the agent allowed to convert the raw filter string to an internal
(schema defined) data type before comparing it to the value from the
target config?

IMO, the post-conversion compare is more user-friendly.

thanks,
Andy

--
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: Martin Bjorklund <[email-masked]>
Date: Mon, 21 May 2007 08:52:40 +0200 (CEST)

> IMO, the post-conversion compare is more user-friendly.

I fully agree.

But we also have this text in 6.2.5:

   o  Leading and trailing whitespace characters are ignored, but any
      whitespace characters within a block of text characters are not
      ignored or modified.

I think that's a mistake.  If I have a xs:string in my db which has
the value " hello ", I cannot match it with a subtree filter.  IMO, it
would have been better to not try to do whitespace adjustments, but
instead follow the normal rules imposed by the datatype.

But I guess the reason for all this is:

   The agent does not need to utilize any data-model specific
   semantics during processing, allowing for simple and centralized
   implementation strategies.

... and now instead for example it's not clear if the float '1.0'
"exactly matches" '1.00' or '1.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 May 2007 07:33:19 -0700

> instead follow the normal rules imposed by the datatype.

Yes.
And the following filter cannot be given  -- &sp;hello&sp; -- because
character entities are not replaced first.  You can never search for
the '<' and '>' characters either.

> "exactly matches" '1.00' or '1.

The string "1.0" does not match "1" or "+1" or "+1.0".

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 May 2007 08:22:38 -0700

>       whitespace characters within a block of text characters are not

This was put in to account for sloppy encoding like:

   <foo>
     1.0
   </foo>

Good managers will avoid introducing significant whitespace into XML content.

> "exactly matches" '1.00' or '1.

I see -- the phrase 'does not need' is not the same as MUST NOT.
Good.  IMO, agents should follow the Postel Principle here, not this text.

<rant>
This is why some of us old-timers are so concerned out CLRs.
When this subtree filtering was specified, text was added
which was thought to help agent implementations.

It turns out (IMO) there are several aspects of subtree filtering
that cannot be supported without special code, and the text meant
to help is actually causing a problem instead.  Without any implementation
experience input at the time it was written, there was no reason
to suspect this would happen.

When a manager sends <foo>1.0</foo> within an edit-config operation,
it will of course be converted to the appropriate data type before it is
compared to the target (e.g., find the corresponding keyed entry,
validate and set the value).

When the same manager sends <foo>1.0</foo> within a <filter> element,
the filter may fail, depending on the exact string sent and the
agent implementation (i.e., convert internal value to string for
exact-match comparison).  Detecting bugs like this can be a nightmare.

A double whammy -- extra work for the agent and astonished, broken managers.
</rant>

Andy

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 21 May 2007 12:26:02 -0700

Hi,

IMHO - Netconf has/had no business attempting to redefine
canonical XML documents/fragments.  There's a perfectly
good existing specification "Canonical XML Version 1.0"
(RFC 3076) that got significant input from W3C experts.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Andy Bierman
Sent: Monday, May 21, 2007 10:23 AM
To: Martin Bjorklund
Cc: [email-masked]
Subject: Re: subtree filtering: content match nodes

   <foo>
     1.0
   </foo>

<rant>

Andy

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.467 / Virus Database: 269.7.6/814 - Release Date: 5/21/2007 2:01 PM

---

From: Li Yan <[email-masked]>
Date: Tue, 22 May 2007 03:36:21 +0800

Hi,
There is no such text (like sec. 6.2.5) to describe how the XPath filter matches the leaf node content in RFC 4741.
Does XPath filtering have the same issue?

Yan

----- Original Message ----- 
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, May 21, 2007 10:33 PM
Subject: Re: subtree filtering: content match nodes

Yes.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 May 2007 12:47:43 -0700

> (RFC 3076) that got significant input from W3C experts.

You mean this document:
http://www.w3.org/TR/xml-c14n

The NETCONF WG is not redefining any aspect of this document.
I don't see any text that describes normalizing numbers.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 21 May 2007 22:18:02 +0200 (CEST)

Li Yan <[email-masked]> wrote:
> Hi,
> There is no such text (like sec. 6.2.5) to describe how the XPath
> filter matches the leaf node content in RFC 4741.  Does XPath
> filtering have the same issue?

I don't think so.  XPath defines comparisons in terms of the nodes'
string-values (possibly by converting to a number).

However, what the string-value for a particular element looks like
isn't defined.  If you use XSD or RelaxNG, you probably will use the
canonical representation of the lexical value in replies to
<get>/<get-config>.  IMO, this is something a "SMI for NETCONF" has to
address.

IMO, subtree filtering should also have been defined to not be
data-model agnostic, and instead compare the canonical form. which
depends on the type.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 May 2007 16:07:54 -0700

> data-model agnostic, and instead compare the canonical form. which

Agreed.
My biggest concern is preventing a situation where the same XML
used in an <edit-config> works differently than when used in a <get>.

For example, if an agent accepts "1.00", "1.0", or "1", as the
value of an 'float' index component during an edit operation,
and they all resolve to the same data model entry (e.g., /foo[index=1.0]),
then those index values should also resolve to that same entry
when used in a <filter> element.

Andy

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 22 May 2007 09:35:46 -0700

Hi Andy,

You're right of course to cite the W3C standards-track
equivalent to RFC 3076 below - thanks.

Rooting around just now on the W3C site about XPath,
I found the following interesting documents (all of
which became full Recommendations in January 2007):

XQuery 1.0 and XPath 2.0 Formal Semantics
http://www.w3.org/TR/2007/REC-xquery-semantics-20070123/

XML Path Language (XPath) 2.0
http://www.w3.org/TR/2007/REC-xpath20-20070123/

XQuery 1.0 and XPath 2.0 Data Model (XDM)
http://www.w3.org/TR/2007/REC-xpath-datamodel-20070123/

The formal semantics spec does talk about integers and
floats in a "formal" manner that leaves me a little fuzzy.

The XDM spec also refers to normalization and canonical
forms.  I don't have the bandwidth just now to digest
them.  I'll look into them in June.

All - Note XPath/2.0 is NOT fully backwards compatible
with XPath/1.0 (which is presumably now referenced by
Netconf RFCs).  But XPath/2.0, by virtue of being
harmonized with XQuery/1.0, is presumably the right
direction for Netconf to take in looking to resolve
matching behaviour for XPath expressions.

Cheers,
- Ira

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]]
Sent: Monday, May 21, 2007 2:48 PM
To: McDonald, Ira
Cc: Martin Bjorklund; [email-masked]
Subject: Re: subtree filtering: content match nodes

You mean this document:

Andy