Chapter 14. XML

Raw information used to be stored in comma-separated lists or .ini files, but for some years the XML standard has prevailed. XML is an acronym for Extensible Markup Language and is a descriptive language for any structured information. In the past, handling XML was difficult, but PowerShell now has excellent XML support. With its help, you can comfortably wrap data in XML as well as read existing XML files.

Topics Covered:

• XML Structure
• Loading and Processing XML Files
  • Accessing Single Nodes and Modifying Data
  • Using SelectNodes() to Choose Nodes
  • Accessing Attributes
  • Adding New Nodes
• Exploring the Extended Type System
  • The XML Data of the Extended Type System
  • Finding Predefined Views

XML Structure

XML uses tags to uniquely identify pieces of information. A tag is a pair of angle brackets like the ones used for HTML documents in a Web site. Typically, a piece of information is delimited by a start and end tag. The end tag is preceded by "/"; the result is known as a node, which in this case is called Name:

In addition, nodes possess attributes, or information relating to the node itself. This information is in the introductory tag:

If a node is empty, the start and end tags can be collapsed. The ending symbol "/" drifts toward the end of the tag. If the branch office in Hanover doesn't have any staff currently working in the sales department, the tag will look like this:

Usually, though, nodes aren't empty and they contain further information, which in turn is included in tags. This allows reproduction of information structures that can be nested as deeply as you like. The following XML structure describes two staff members of the Hanover branch office who are working in the sales department.

So that XML files can be recognized as such, they usually begin with a header, which in a very simple case might look like this:

This header declares that the subsequent XML conforms to the specifications of XML version 1.0. What is known as a "schema" could also be given here. Specifically, a schema has the form of an XSD (XML Schema Definition) file and describes what the valid structure of the XML file should be to fulfill a certain purpose. In the previous example, the schema could specify that there must always be a node called "staff" as part of staff information, which in turn could include as many sub-nodes named "staff" as required. The schema would also specify that information relating to name and function must also be defined for each staff member.

Because XML files consist of plain text, you can easily create them using any editor or directly from within PowerShell. Let's save the previous staff list as an xml file:

Loading and Processing XML Files

If you want to process XML files as actual XML and not as text, the text contents must be converted into the XML type. The type conversion covered in Chapter 6 performs this task in just one line:

Use Get-Content to read the XML from the previously saved xml file and [xml] to convert the XML into genuine XML. You could just as easily have directly specified the XML from the $xml variable:

However, conversion works only if the specified XML is also valid and contains no syntactic errors. You'll get an error when trying to convert if the structure of your XML is faulty.

The structure of information that describes the XML is now included in $xmldata. From now on, it will be very easy to retrieve single pieces of information because the XML object represents each node as attributes. You can get a staff list like this:

Accessing Single Nodes and Modifying Data

If a node in your XML is unique, you can access it by typing a dot as in the previous example. Often, however, XML documents contain many similar nodes (known as siblings) just as the last example includes individual employees. For example, you could use the PowerShell pipeline if you'd like to access a particular employee to modify his data:

Using SelectNodes() to Choose Nodes

The SelectNodes() method, which the XPath query language supports, also allows you to select nodes. XPath specifies the "path name" to a node:

The result looks just like the direct accessing of attributes in the preceding example. However, XPath supports wildcards enclosed in square brackets. The next statement retrieves just the first employee node:

If you'd like, you can get a list of all employees who are under the age of 18:

In a similar way, the query language will also retrieve the last employee on the list. Position specifications are also possible:

Accessing Attributes

Attributes are information defined in an XML tag. If you'd like to see the attributes of a node, use get_Attributes():

Use GetAttribute() i f you'd like to query a particular attribute:

Use SetAttribute() to specify new attributes or modify (overwrite) existing ones:

Adding New Nodes

If you'd like to add the names of new employees to the employee list, first use CreateElement() to create an employee element and then to lay down its inner structure. Afterwards, the element can be inserted at the desired location in the XML structure:

Exploring the Extended Type System

The PowerShell Extended Type System (ETS) ensures that objects can be converted into meaningful text; moreover, it can pass additional properties and methods to objects. The precise instructions for these operations are laid down in XML files having the .ps1xml file extension.

The XML Data of the Extended Type System

Whenever PowerShell has to convert an object into text, it searches through several of its own internal records to find any that describe the object and its conversion. The right files contain XML; their name ends with .format.ps1xml. These files are located in the PowerShell root directory $pshome:

All these files define a multitude of Views, which you can examine using PowerShell XML support.

Finding Predefined Views

Predefined views are highly interesting because you can use the -view parameter to make extensive adjustments and modifications of results given by formatting cmdlets like Format-Table or Format-List.

Unfortunately, there's nobody to inform you of the availability of the Priority and StartTime predefined views or of other views. You can look in the relevant XML files. The view shows that every view node contains the child nodes Name, ViewSelectedBy, and TableControl. But the raw XML data of the view may look confusing and unclear at first:

A little re-formatting results in text that's easier to read:

Each view consists of a Name, a .NET type in ViewSelectedBy for which the view is valid, as well as the TableControl node specifying how the object is supposed to be converted into text. Just use Format-Table to output the data if you want to output all the views specified in the XML file in columns, . Then, select the properties that you want to show in the summary:

Here you see all of the views defined in this XML file. The object types for which the views are defined are in the second column. The Priority and StartTime views, which we just used, are also on the list. After a look at the second column, it should be clear that the views are intended for System.Diagnostics.Process objects, precisely the objects that Get-Process retrieves:

Surprisingly, doubles of some names crop up. The reason is that, along with the TableControl node in the last example, other nodes convert objects: ListControl, WideControl and CustomControl. These nodes weren't displayed in the first overview simply because only one node of this kind is allowed for each view. A TableControl was output more or less randomly since PowerShell bases its text conversion of unknown objects on the first record.

You are now in a position to extract all required information from the XML file. First, sort the views by ViewSelectedBy.TypeName, and then group them by this criterion. You can sort out all the views that match only once for a particular object type. You need only those views of which several exist for an object type, making it worthwhile to use the -view parameter for the selection.

The result is an edited list that provides you with the names of all the views in the first column. The view that is appropriate for a respective object type is in the second column. The third column shows whether a view is meant for Format-Table, Format-List, Format-Wide or Format-Custom.

Remember that there are several XML files containing formatting information. You'll only get a full overview of them when you generate a list for all formatting XML files.