[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: subtree filtering: content match nodes

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

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.


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.


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.



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.




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



/martin


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