Known Limitations

Custom properties assigned to an ActionScript XMLNode (and XML) object will not persist if all references to that object is dropped and accessed again. When all references are dropped, only the ActionScript object is removed. The DOM tree behind the scenes will persist. But since custom properties are applied to the ActionScript object and not the DOM, the properties’ lifetime is directly related to the lifetime of the ActionScript object.

This case can occur when a document is loaded through XML.load, which creates a top level XMLNode object that shadows a complete DOM tree behind the scenes. If the user traverses the DOM tree in ActionScript using temporary XMLNode references and assigns custom properties to those temporary references, they will not exist when accessed later on. For example (assuming root is an XML or XMLNode object that has valid XML data):

// Get reference to a DOM node
XMLNode temp = root.firstChild;
// Set a custom property to the node
temp.someProperty = someValue;
// Drop the reference (all references)
XMLNode temp = temp.nextSibling;
// Get back the reference
temp = temp.prevSibling;
// Look for the custom property
trace(temp.someProperty)

The output will be someValue in Flash™, but will be undefined in Scaleform because the XMLNode object does not hold the previously assigned property anymore. The property will exist if a reference to it persisted through custom property assignment and the trace statement.

Note: This does not affect the attributes object that is attached to an XMLNode. Setting properties to this object will persist regardless of the state of ActionScript XMLNode references. For example:

// Get reference to a DOM node
XMLNode temp = root.firstChild;
// Set a custom attribute to the node
temp.attributes.someProperty = someValue;
// Drop the reference (all references)
XMLNode temp = temp.nextSibling;
// Get back the reference
temp = temp.prevSibling;
// Look for the custom attribute
trace(temp.attributes.someProperty)

The output will be some Value in Scaleform.

This property was not implemented because of the various inconsistencies that arise when mapping error codes from a custom parser library to the ActionScript 2.0 XML error codes, e.g.,

ActionScript error codes:

• 0 No error; parse was completed successfully.
• -2 A CDATA section was not properly terminated.
• -3 The XML declaration was not properly terminated.
• -4 The DOCTYPE declaration was not properly terminated.
• -5 A comment was not properly terminated.
• -6 An XML element was malformed.
• -7 Out of memory.
• -8 An attribute value was not properly terminated.
• -9 A start-tag was not matched with an end-tag.
• -10 An end-tag was encountered without a matching start-tag.

Expat to ActionScript mapping:

    //
    // XML_ERROR_NONE           = 0
    // XML_ERROR_INVALID_TOKEN  = 0 (ie: XML.parse("http://www.google.com"))
    // XML_ERROR_UNCLOSED_CDATA_SECTION = -2
    // XML_ERROR_UNCLOSED_TOKEN = -3
    // XML_ERROR_INVALID_TOKEN  = -4
    // XML_ERROR_INVALID_TOKEN  = -5
    // XML_ERROR_UNCLOSED_TOKEN = -8
    // XML_ERROR_NO_ELEMENTS    = -9
    // XML_ERROR_TAG_MISMATCH   = -10
    //

Implementing a consistent status property is not possible without a one-to-one mapping of the error codes. The GFx::XML::DOMBuilder prints verbose error messages to debug output using data from the GFx::XML::ParserLocator object registered with it by the XML parser instance.

From Flash® documentation: “The ActionScript XML parser is not a validating parser. The DOCTYPE declaration is read by the parser and stored in the XML.docTypeDecl property, but no DTD validation is performed.” This property has no use in both Flash and Scaleform, therefore it was omitted.