Subject: xpath filter

From: Martin Bjorklund <[email-masked]>
Date: Sun, 11 Dec 2005 21:20:34 +0100 (CET)

Hi,

I know that this has been up on the list before, but I never saw any
replies.  The question is how to handle namespaces with the xpath
capability.  Consider the example in 8.9.5.1:

         <filter type="xpath"> <!-- get the user named fred -->
           top/users/user[name="fred"]
         </filter>

If the box supports multiple namespaces, which namespace does top
belong to?  You could argue that this is a filter, so it should return
results from all namespaces which match the filter.  But what if you
want to explicitly match a certain namespace?

The XPath specification says that an xpath expression is evaluated
with respect to a context
(http://www.w3.org/TR/xpath#section-Introduction).  A context
contains, amongst other things, the set of namespace declarations in
scope for the expression (a mapping from prefixes to namespace URIs).

As one example, XSLT defines the context in
http://www.w3.org/TR/xslt#section-Expressions.  It defines the
namespace declarations as:
  
  the set of namespace declarations are those in scope on the element
  which has the attribute in which the expression occurs; this
  includes the implicit declaration of the prefix xml required by the
  the XML Namespaces Recommendation [XML Names]; the default namespace
  (as declared by xmlns) is not part of this set

I suggest that NETCONF uses a similar definition, so that one can
write a filter such as:

  <filter type="xpath" xmlns:d="http://www.example.com/Datamodel">
     d:top/d:users/d:user[name="fred"]
  </filter>

Also, I think that the XPath Core functions should be sufficient for
NETCONF compliance; this is also not defined in the current draft.

/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: Cridlig Vincent <[email-masked]>
Date: Mon, 12 Dec 2005 07:27:12 +0100

Martin Bjorklund wrote:

>Cridlig Vincent <[email-masked]> wrote:
>  
>
>>I totally agree with your suggestion.
>>I proposed earlier on this list to add a "contexts" element, seebling of 
>>"filter", and containing one or more "context" elements (namespace + 
>>prefix).
>>    
>>
>
>Yes, I know.  I just hope we get a reply this time!
>
>  
>
>>It will be much much more efficient (at least in our Netconf 
>>implementation) to find the right XML nodes in the case of such XPath 
>>relative expression: "//name"
>>    
>>
>
>Same here.
>
>  
>
>>Moreover, the XPath expressions without prefix are still valid.
>>    
>>
>
>Do you check all namespaces in this case?
>  
>
yes. Actually, we load the entire configuration data and then apply a 
filter (easy solution but not performant).
Ideally, it should parse the XML schemas to find some matching nodes (or 
search in a dictionnary built from the schemas), load the configuration 
data of each matching schemas and finally filter.

For now, namespaces are not very well handled in our agent because I was 
waiting for some clarifications on this context problem. Still some work 
in the pipe...

What about you ?

Vincent

		
___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

---

From: Cridlig Vincent <[email-masked]>
Date: Sun, 11 Dec 2005 21:46:00 +0100

I totally agree with your suggestion.
I proposed earlier on this list to add a "contexts" element, seebling of 
"filter", and containing one or more "context" elements (namespace + 
prefix).
But I think the way you propose is more generally accepted in the XML 
community.

Vincent CRIDLIG
Madynes

	

___________________________________________________________________________ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
TÃ©lÃ©chargez cette version sur http://fr.messenger.yahoo.com

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Dec 2005 10:25:03 +0100 (CET)

> waiting for some clarifications on this context problem. Still some work 

Our agent knows the data model, and thus we can do two things when
filtering: if the filter uses a instance key, we just read the
corresponding instance and continue filtering down there.
(e.g. "interfaces/interface[ifName=eth0]/...")
When no instance identifier is specified
(e.g. "interfaces/interface[ifType=ethernet]/...") we check the match
nodes (in the example ifType of each instance, if a match is found we
read the rest of instance.  This means that if you just want to read
one or a few parameters in a given instance, we'll just do one read to
the db to get the instance.

As for namespaces for xpath, we don't handle that either - we're also
waiting for clarification.  For subtree filtering we handle
namespaces though.

/martin

---

From: Vincent Cridlig <[email-masked]>
Date: Mon, 12 Dec 2005 11:04:52 +0100

If I understand well :-)
1.
- you optimize your tool to limit the reading in your database *per value*
- we optimize our tool to limit the reading *per module*
2.
- you parse the XPath expression to build the XML document little by little
- we build a brute subset XML document, and then we use an existing 
XPath library to select the nodes (so we have a full support of XPath). 
But it's better for us if the XPath expr starts in the same way as the 
registration XPath expr of an existing module. Otherwise, we have to 
query all modules... :-(  (Hence the contexts, namespaces and prefixes...)

You must have better performances but you have to reimplement XPath, 
don't you ?
I guess that, in most cases (except for the relative expressions and 
exotic XPath requests), it probably looks like subtree filtering.

Thanks for your replies. I find it very interesting to compare 
implementation choices.

Vincent

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Dec 2005 21:59:04 +0100 (CET)

Hi again,

There's another place where namespaces declarations need to be
provided - the 'error-path' element.  This is a bit different than the
other, since xpath is just used to point to an instance.  But
namespaces need to be handled.  I suggest that the namespace
declarations set is the namespaces in scope of error-path, so that an
agent can generate the following error-path:

   <error-path xmlns:d="http://www.example.com/Datamodel">
      d:top/d:users/d:user[name="fred"]/d:companyInfo/d:dept
   </error-path>

/martin