Exploring XML and RSS in Flash (2/4) - exploring XML
Exploring XML and RSS in Flash
Parsing the XML
Parsing XML documents is accomplished by XML processors as defined by W3C:
- A software module called an XML processor is used to read XML documents and provide access to their content and structure.
Reading this definition carefully reveals two fundamental points: First, a parser (pardon me: XML processor) can read XML, in other words it can understand documents that comply with the XML Specification. Secondly, it can access the document's content and structure where the XML Specification only provides basic information about what a XML processor should do. There is no mention about the API used to get the information from the document. For XML the Document Object Model (DOM) and the Simple API for XML (SAX) are the most famous APIs.
Let's make different changes to our XML file, then load it in a player and see how the player deals with different failures and some entities XML provides.
Not a validating parser
The status of the parsing process is stored in the property status
of the
Actionscript XML object. You can easily create malformed
XML to receive status -8 (An attribute value was not properly terminated)
or -9 (A start tag was not matched with an endtag). Receiving a status
of
-7 (Out of Memory) depends on your computer's memory resources.
As you will see later, Actionscript distinguishes between two types of XML objects,
texts and elements. So what about other
XML elements like W3C XML comments?
Not closing a comment properly lets parsing fail with status
-5 (A comment was not properly terminated), but otherwise the comment will be stripped
from the XML: A call to the toString()
of an XML object containing comments will return
it with whitespaces instead of the comment.
Next, we tested how the parser deals with W3C XML Processing Instructions. A common situation is when you want to avoid the dubious caching in different combinations of browser and player by adding the code from the PHP manual instead of using random numbers in the URL.
<?php header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); // always modified header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/1.1 header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); // HTTP/1.0 ?> <?xml version="1.0" ?> <skipintrobutton text="Skip Intro!">"Skip Intro!"</skipintrobutton>
If the file is sent to the player by a php enabled webserver the processing instruction
is removed and the headers are set. When developing with a local copy that isn't
processed by php before trace(myXML.status)
returns -6
(An XML element was malformed.)
Please notice that if parsing results in a status
different from
0 (No error; parse completed successfully), this doesn't mean that the XML
object is empty or undefined. Invoking the toString()
method on
the XML object returns all the XML parsed until the error occured.
The documentation for the docTypeDecl
property of an Flash XML object states
that ActionScript's XML parser is not a validating parser. This also means no external
DTD are processed. The W3C Definition says for
non-validating processors:
- While they are not required to check the document for validity, they are required to process all the declarations they read in the internal DTD subset and in any parameter entity that they read, up to the first reference to a parameter entity that they do not read; that is to say, they must use the information in those declarations to normalize attribute values, include the replacement text of internal entities, and supply default attribute values.
The author found that the replacement text of internal entities isn't
included. Declaring an empty element <!ELEMENT skipintrobutton EMPTY>
also doesn't affect the parsing process at all. It seems that all internal DTDs
are simply ignored, and the parser deals with every element(node) as if it was
declared like this <!ELEMENT anyelement ANY>
.
So Actionscript's XML parser is not a validating parser, but it's also not a non-validating processor as defined by the W3C. In the next article, we'll show some interesting consequences of this behaviour and deliver some more code pieces after this more theoretical description.
Let's look at the DOM differences...
Produced by Michael Claßen
URL: https://www.webreference.com/xml/column80/2.html
Created: Apr 28, 2003
Revised: Apr 28, 2003