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

Re: namespaces in subtree filtering

Martin Bjorklund wrote:

Phil Shafer <phil@juniper.net> wrote:

Martin Bjorklund writes:

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.

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



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


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.



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:circuitIdentif
ier>
    </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>
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.


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?

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.


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


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




/martin

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





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