cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
931
Views
3
Helpful
4
Replies

XPath Queries

rruckley
Level 1
Level 1

Team,

I'm doing a web service execute which produces the following output:

<?xml  version="1.0" encoding="utf-16" ?>

  <RetrieveRelationshipKeysListResponse  xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" status="SUCCESS"  message="Success" schemaRevisionDate="2012-08-31" schemaRevisionLevel="1"  returnCode="0" query="">

-      <keys xmlns="http://schemas.hp.com/SM/7">

            <RelationshipName  type="String">Service Components</RelationshipName>
            <ParentCI type="String">EBC Managed Services</ParentCI>

  </keys>

  </RetrieveRelationshipKeysListResponse>

All I wish to do is collect the content of the ParentCI node using an XPath query:      //ParentCI

But the XPath operation simply says it can't find it. I haven't defined any namespaces and perhaps this could be the problem but as you can see the node uses the default namespace.

Perhaps I need to define all of them?

--

Ryan

4 Replies 4

Shaun Roberts
Cisco Employee
Cisco Employee

//ParentCI is not the proper XPath for that XML. Two things need to happen to get that to work....

1) Remove the XMLNS string from the keys tag, so take out

xmlns="

http://schemas.hp.com/SM/7"

this is not too hard with the replace string function, just do a replace string of that part and replace it with a blank space.

This is not just in CPO, if you tried to use this same part in Notepad++ with it's *standard* XML tools plugin, it would not work with that XMLNS in it.

2) Run the proper XPath Query of

/RetrieveRelationshipKeysListResponse/keys/ParentCI

I was able to do this in CPO without issue. I would suggest you go get Notepad++ and the XML Tools plugin for it as well. This allows you to test your XML, XSLs, and XPath queries before you input them into other products. Highly useful for testing and debugging.

-Shaun

--Shaun Roberts
Principal Engineer, CX
shaurobe@cisco.com

Chris,

     A few points:

  • the double slash is a legitimate XPath search but obviously one not supported by CPO
    OR
  • the xml namespace declaration is confusing things.

Possibly both. I will try out the suggestion of removing the xmlns attribute in the keys node and see if that makes a difference.

I have also managed to solve it with ah XSLT transform outputting as text as an alternative, after using a regex to extract just the ParentCI node. I will also try to see if I can use XSLT alone to extract the contents of the ParentCI node as that would be a bit more elegant.

Here is my XSLT for reference:

http://www.w3.org/1999/XSL/Transform" xmlns:k="http://schemas.hp.com/SM/7" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

   

   

         

   

What do you think?

--

Ryan

Hello, Ryan!

CPO absolutely supports double slash, and all the standard XPath constructs. The issue with your XPath query of //ParentCI is exactly what you suspected (the namespaces).

Let's look at this XML closely...

  http://schemas.hp.com/SM/7">

            Service Components

            EBC Managed Services

 

What xlms="blah" in the key element means is that there is a "default" (unnamed) namespace defined for all elements and sub-elements within key tag. So the proper names for all those tags are not keys, ParetCI and RelationshipName, but the ones with a namespace "prefix". What is clearly confusing, is that while the XML does define the namespace, it omits (defaults) the prefix.

Given this XML, when you are searching for any tag within tag key you need to "prefix" your search with a namespace.

So what you need to do to make your query work in XPath Query activity is

  1. Define namespace with any prefix (e.g. k) and URI: http://schemas.hp.com/SM/7
  2. Define your query as //k:ParentCI

And that should produce the answer you  are looking for.

Svetlana,

I send greetings from Mike Whiteley.

The solution above worked a treat. XPath matches now work as expected. Thanks again.

--

Ryan