Processor Instructions

XML anticipates the need to embed code within a data document. The PI is a mechanism to contain such code. Each PI node identifies the target, the application that will interpret and execute the code. It follows the target identification with the code itself. The XML standard establishes few protocols for engaging this process. It does, however, require parsers to maintain the PI nodes and make them available to the application.

Flash Context

Flash does not like processor instructions. The PI data is not preserved. Even if it were, it could not contain real ActionScript code and make it executable by the application. That would require the Flash player to include an ActionScript interpreter. For reasons of size , it does not. Anyone who has used the eval() operator in Flash and elsewhere will recognize that the Flash implementation is extremely limited. This limitation is to avoid burdening the player with a full interpreter.

But it is worse . At presstime, a bug in the Flash parser misinterprets the PI and recovers poorly. All subsequent data is incorrectly positioned in the hierarchy. Since this bug corrupts the entire XML object ”sometimes trivially, often fatally ”it would be unwise to include PI material in any XML meant to integrate with Flash. If it is unavoidable (i.e., it is someone else's data), you should check. The PI bug may be corrected by the time you read this. If not, you might need to use an XLS preprocessor to filter the XML (or use a server-based proxy) or you might sign up for some heavy sessions inside the Flash debugger, determining the specific behavior you need to code around.

Syntax

PI begins with <? and ends with ?> . Between these is any text. The syntax is defined by the foreign processing language, not by XML. The XML parser will not interpret this text, nor will it expand any embedded entity references.

Rules

Each PI must have

• the opening character pair <?

• the target application (or device) to which the PI is directed

• whitespace

• the actual processing instruction stream

• the closing character pair ?>

It may have

• any characters whatsoever up to the closing ?> .

It may not have

• an embedded ?> pair

• entity references that are meant to be expanded

Examples of PI

<?php counter++; ?>	Embedded line of PHP script
<?xml version='1.0'?>	Standard XML declaration is a PI to the XML processor.
<?xm-replace_text { Click here} ?>	Proprietary instruction of the XMeTal editor

Bad Examples

<?mathpro 3.1?>x**2=>n! ?>	Forbidden characters in string
<?actionscript this.nextFrame(); ?>	Not yet, not yet

Note

XML FOR THE HTML E XPERT

XML will feel familiar to the HTML coder . It has the same notions of start and end tags enclosing very loosely defined text data. They both interject well-specified attribute data within the body of the opening tag.

In practice, XML is far stricter than HTML. Coders used to the forgiving nature of web browsers and the lax definition of many HTML tags should prepare for a more stringent environment. Respect the following differences:

Case sensitivity. HTML is not sensitive to case; XML is.

<Price> is not the same as <PRICE> .

< name > will not be terminated by </Name> .

Explicit end tags. HTML tolerates unclosed elements. XML does not.

Stand-alone <P> and <br> will not work.

<P></P> and <br></br> will work.

Stand-alone <P/> and <br/> will work.

Value delimiters. HTML permits unquoted attribute values. XML does not.

<OBJECT width=100> does not work.

<OBJECT width="100"> works.

Proper nesting. HTML permits element overlap. XML is strict.

"I just <B><I>know</B></I> it!" will not process.

"I just <B><I>know</I></B> it!" will.

XHTML

Since XML is more demanding than HTML but similar in syntax, it is possible to write proper HTML that is legitimate XML as well. This more formal HTML is called XHTML. It is HTML 4.0 that follows the disciplines required to be well- formed and a few others required to be valid.