Subject: namespaces in subtree filtering

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Mar 2007 10:54:01 +0100 (CET)

Andy noted at the meeting that subtree filtering can't be used to
retreive elements from mulitple namespaces.

The text from rfc4741, section 6.2.1 says:

   If namespaces are used, then the filter output will only include
   elements from the specified namespace.  A namespace is considered to
   match (for filter purposes) if the content of the 'xmlns' attributes
   are the same in the filter and the underlying data model.

This is somewhat difficult to interpret.  What exactly does "the
'xmlns' attributes" mean?  Note the plural.

Suppose we have this in the database:

   <if:interfaces xmlns:if="http://example.com/interface">
     <if:interface>
       <if:ifIndex>1</if:ifIndex>
       <if:ifType>ds0</if:ifType>
       <ds0:circuitIdentifier xmlns:ds0="http://example.com/ds0">foo</ds0:circuitIdentifier>
     </if:interface>
   </if:interfaces>
 
Accordning to the example in 6.2.1, the following filter:

   <get>
     <filter>
       <if:interfaces xmlns:if="http://example.com/interface"/>
     </filter>
   </get>

would return

   <if:interfaces xmlns:if="http://example.com/interface">
     <if:interface>
       <if:ifIndex>1</if:ifIndex>
       <if:ifType>ds0</if:ifType>
     </if:interface>
   </if:interfaces>

Suppose instead the filter is

   <get xmlns:if="http://example.com/interface">
     <filter>
       <if:interfaces/>
     </filter>
   </get>

Note that no xmlns attributes are present in the filter itself.

Would we get the ds0 elements as well?

What about this filter:

   <get>
     <filter>
       <if:interfaces xmlns:if="http://example.com/interface"
                      xmlns:ds0="http://example.com/ds0"/>
     </filter>
   </get>

Here we have two xmlns attributes.  Would we get the ds0 elements in
this case?

IMO, it's unfortunate that the xmlns attribute is overloaded with this
filter semantics.  I don't really see the value in this namespace
selection mechanism at all.  Are there any use cases where it makes
sense?

/martin

--
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: Phil Shafer <[email-masked]>
Date: Wed, 21 Mar 2007 07:42:35 -0500

>'xmlns' attributes" mean?  Note the plural.

I interpret this as an element by element rule, meaning that
the filter will only match elements which match the name and
namespace of element in the filter.  This rule is applied
recusively, so that if your data looks like:

  <a:a>
    <b:b>
      <c:c>4</c:c>
    </b:b>
  </a:a>

and you use the filter:

  <a:a>
    <b:b/>
  </b:b>

your output would include <c:c>.  If you used the filter:

  <a>
    <b/>
  <a>

you would get nothing, since the namespace don't match.

>       <if:ifType>ds0</if:ifType>

I would rather see all of <if:interface> emitted.  If you use
this strict interpretation, your application will need to send
every possible namespace to get a full tree, which is impossible.
Given that this full fetch is a normal and useful scenario, it
shouldn't be impossible, so we shouldn't do the strict interpretation.

>Here we have two xmlns attributes.  Would we get the ds0 elements in

Remember that the use of xmlns is only an encoding issue.  The XML
information model defines the element as belonging to a namespace,
and the prefix (and the xmlns attribute that defines the prefix
mapping) is an encoding issue, not a semantic one.

This means that an unused prefix is meaningless, so trying to
use 'xmlns:ds0' like this won't work.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 21 Mar 2007 16:10:23 +0100 (CET)

Phil Shafer <[email-masked]> wrote:
> your output would include <c:c>. 

There's an example in 6.2.1 which says:

   <filter type="subtree">
     <top xmlns="http://example.com/schema/1.2/config"/>
   </filter>

   In this example, the <top> element is a selection node, and only this
   node and any child nodes (from the underlying data model) in the
   'http://example.com/schema/1.2/config' namespace will be included in
   the filter output.

Which is not compatible with what you say above.

> I would rather see all of <if:interface> emitted. 

So would I.  My question is how the specs should be interpreted.  And
a follow-up question is if the specs should be changed in the future.

> mapping) is an encoding issue, not a semantic one.

Yes I know.  That's what I tried to say in my email.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Wed, 21 Mar 2007 11:52:24 -0500

>Which is not compatible with what you say above.

Which is unfortunate.  Can we declare this a bug and get it patched?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Mar 2007 09:52:50 -0700

>> your output would include <c:c>. 

I did not get the details right -- sorry.
I agree with your example -- my code works this way too,
and I believe the spec intends to have this behavior and it is
properly defined to work this way.

The corner-case that would not match is if the <c> node
did not include a namespace:

   <a:a>
      <b:b>
         <c/>
      </b:b>
  </a:a>

In this case, nothing will be returned because <c> is not defined in the 
'b' namespace.
Sorry for causing this confusion.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 21 Mar 2007 12:05:27 -0500

>In this case, nothing will be returned because <c> is not defined in the 

But it should match.  Anything that doesn't fail a match explicitly
in the filter should be returned.

    <a:a>
      <b:b/>
    </a:a>

should be equivalent to the xpath expression:

   a:a/b:b

which should match the entire contents of anything under a b:b node
that is under a c:c node.  If this isn't true, life gets ugly.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Mar 2007 11:01:45 -0700

> that is under a c:c node.  If this isn't true, life gets ugly.

But there is a namespace in affect for <c>.
What if the filter is given this way:
 
<a:a xmlns:a="blah">
     <b xmlns="foo">
        <c/>
     </b>
 </a:a>

The namespace does not have to be explicit, but
there is usually a namespace in effect, since our <rpc> method
node is in a namespace, and the content is in a different namespace.

If you had this corner case, then <c> would be returned:

<a:a xmlns:a="blah" xmlns="">
     <b:b xmlns:b="foo">
        <c/>
     </b:b>
 </a:a>

If we agree on a 'clarification' for the protocol spec,
I would glad to change my code to work the way you are suggesting,
but it will require hacks to check for explicit 'xmlns' directives
instead of relying on the effective namespace derived by the parser.

Andy