Item 17. Use Processing Instructions for Process-Specific Content

Processing instructions are certainly useful, but they can be a source of interoperability problems. They are not normally validated , and many processes ignore them by default. SOAP, the Extensible Messaging and Presence Protocol (XMPP), and a few other applications have even chosen to forbid them (in violation of Item 14, I'll note). Be careful not to use processing instructions for information that really deserves to be part of the markup instead. The correct purpose of processing instructions is, naturally enough, to give instructions to particular processes that read the XML document. The following characteristics normally indicate that a processing instruction is warranted.

The information is intended only for a very particular process, often a purely local one, not for a large portion of the programs that will read a document.
The instruction describes how a particular process acts on the data in the document. It does not describe or add to the data itself.
The processing instruction is a unit that can be treated in isolation. It does not extend across a range of the XML document.
The content of the processing instruction does not need to be validated.
The content of the processing instruction is simple and not very XML-like.
The processing instruction logically applies to the entire document, not to a specific element, even the root element.
The processing instruction applies to multiple document types.

When are processing instructions not appropriate? I can think of two main criteria:

When their content is closely related to the content of the document itself
When they have structure that extends beyond a single processing instruction

In both cases, processing instructions are being used as a sort of pseudo-tag. This sidesteps the normal XML parsing and validation process and eliminates some of the customary benefits of XML. Let's explore these criteria by investigating common usages of processing instructions, both good and bad.