Using PowerShell to Explore Structure of an XML Document
Summary: Microsoft Scripting Guy, Ed Wilson, talks about using Windows PowerShell to explore the structure of an XML document.
Microsoft Scripting Guy, Ed Wilson, is here. I don’t know about you, but when I decide to script, I often do a cost/benefit analysis. I am not talking about anything extensive or anything that is even formalized. But I do estimate how long it will take to do something manually, and then I estimate how long it will take to do the same thing with Windows PowerShell. As you may well know, quite often Windows PowerShell wins. But not always. The not always areas are often because I may not know or understand an underlying technology well enough to script it.
   Note This is the third in a series of posts about XML. You might also enjoy reading:
Windows PowerShell is not “magic pixie dust.” It is an automation technology. To successfully automate, I often must know and understand the underlying technology. The better the Windows PowerShell cmdlets abstract this requirement, the easier it is for a non-expert to automate.
But at some point, I need to know what I am doing. For example, there are 27 cmdlets that contain the characters *firewall* in the noun. To successfully automate firewall stuff, I need to know the relationship between the firewall rules, address, application, interface, and port filters. I also need to understand the relationship between rules, filters, settings, and profiles.
Clearly, there is going to be a bit of reading before I really mess stuff up. In general, I like to ease into things gently by using the **Get*** types of cmdlets before I get to carried away with the **Set***, **New***, **Enable***, and **Disable*** cmdlets.
XML document structure
When I read an XML document into a variable, I like to see what is available. I like to pipe the XMLDocument to **Format-List **and look at the values of all properties. This is shown here:
I can see that the XML node does not contain a lot of extremely useful information. I see that Users says Users, and that the Name and the LocalName are both #Document. The DocumentElement is Users. Nothing I need here.
Although this is interesting, I am trying to see the data. One area that looks promising is InnerXML. It definitely contains the data for all of the user nodes. It is shown here:
I can, call the Split method, and split on both < and />. This command will clean up the output a bit:
$users.InnerXml.Split(‘‘)
The output associated with the command is shown here:
Of course, that is not really working with XML, it is simply avoiding the problem of how to work with XML. I go back to my Format-List output, and I can see that there are more interesting properties exposed, Â such as the ChildNodes property that lists the child nodes, the LastChild property, and the HasChildNodes property.
All of these could be useful from a navigation perspective. The OuterXML looks an awful lot like the InnerXML, so I do not need to mess with that. The following image shows the properties and their associated values:
From all of this, I can see the best path for me to pursue, is to go into the Users node, and look at the individual User objects. This is shown here—and it takes us back to where we left off yesterday.
PS C:\> $users.Users.User
Â
ID                           UserName                     Address
—Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ——–Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ——-
0                            UserName                     Address
0                            UserName                     Address
0                            UserName                     Address
0                            UserName                     Address
0                            UserName                     Address
The point to all this?
Well, it helps to know a bit about XML to avoid doing a lot of extra work, such as manually trying to parse (by using string methods) XML data. XML data is already formatted. I only need to know what it looks like, and I can easily use Windows PowerShell to retrieve the data I need or want.
That is all there is to using Windows PowerShell to work with XML. XML Week will continue tomorrow when I will talk about more cool Windows PowerShell stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting GuyÂ
Light
Dark
0 comments