- Flash Context
- Name
- Start Tag
- End Tag
- Attributes
- Text (Character Data)
- Entity References
- Comments
- Processor Instructions
- Conclusion
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 objectsometimes trivially, often fatallyit 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 Expert
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.