Focus of PowerTools for Open XML: Developers, Developers, Developers
Many, many years ago, Stephen C. Johnson, the creator of many UNIX tools at AT&T made the statement that using the command line of mainframe computers was ‘like kicking a dead whale down the beach’. He was referring to the difference between old style monolithic command lines, and the UNIX shell scripting system that enables a bunch of small utilities to work together by piping text from one to the next.
PowerShell is the spiritual successor to UNIX style shell scripting. One key innovation is the ability to pipe and work with objects of any type instead of text. Another innovation is a set of rules and guidelines that make Cmdlets have a consistent and predictable pattern. While much of PowerShell is oriented towards system administrators, enabling them to create, update, and maintain many servers with a minimum of effort, the characteristics of PowerShell make it ideal for developers to use in their day-to-day work cycle. Because Open XML documents are not simply text, PowerShell’s ability to work with classes and objects is essential to providing small, single functionality Cmdlets that enable us to slice and dice documents, spreadsheets, and presentations. Many of the activities that you need to do in the process of building Open XML applications are made easier by the power of PowerShell scripts, including examining and changing Open XML documents, making sure that documents are valid, working with Git, testing and moving documents around, and so on. You can do stuff faster and easier.
I have to admit – when I originally designed the Cmdlets for PowerTools for Open XML, I (partially) missed the mark. In my defense, at the time I was new to Open XML, and new to PowerShell. Now, with several years of Open XML development under my belt, and as I gained competence in PowerShell and started using it every day, I started considering how I would re-design the various Cmdlets to make life easier for a busy Open XML developer. PowerTools for Open XML 3.0 is the result.
My latest foray is a new Cmdlet, Get-DocxMetrics, which returns a lot of useful information about a WordprocessingML document. A summary of the information it returns for a document:
- The style hierarchy – styles can inherit from other styles, and it is helpful to know what styles are defined in a document.
- The content control hierarchy. We can examine the hierarchy, and design an XSD schema to validate them.
- The list of languages used in a document, such as en-US, fr-FR, and so on.
- Whether a document contains tracked revisions, text boxes, complex fields, simple fields, altChunk content, tables, hyperlinks, legacy frames, ActiveX controls, sub documents, references to null images, embedded spreadsheets, document protection, multi-font runs, the list of numbering formats used, and more.
- Metrics on how large the document is, including element counts, average paragraph lengths, run count, zero length text elements, ASCII character counts, complex script character counts, East Asia character counts, and the count of runs of each of the variety of characters.
These metrics are super useful to us as Open XML developers. If we have a large sample document set, and we want to select
certain documents to use in testing, the ability to find select documents enables us to focus our testing, minimize time to run tests, and get our job done faster. Here is a screen-cast that discusses Get-DocxMetrics, and demonstrates its use: