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 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.
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.
Each PI must have
It may have
It may not have
Examples of PI
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.
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.