RE: subtree filtering: content match nodes

["McDonald, Ira" <imcdonald@sharplabs.com>]

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: imcdonald@sharplabs.com

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Andy Bierman
Sent: Monday, May 21, 2007 10:23 AM
To: Martin Bjorklund
Cc: netconf@ops.ietf.org
Subject: 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.

This was put in to account for sloppy encoding like:

   <foo>
     1.0
   </foo>

Good managers will avoid introducing significant whitespace into XML content.

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

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>


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

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
 

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