I see people shuttling their XML data into the VO. But sometimes I'd kind of rather not do this...but instead just hold the loaded XML in an E4X friendly object. Does that mean I can't be in the PureMVC club anymore?
No, rest easy, you can still be in the club.
That's why notification body is of type object. Send whatever you want. That's none of PureMVC's business.
But from a pure OOP standpoint I advise you to avoid passing around the XML and instead to use a SmartVO
When you're just passing XML from the server to the client, unless you are validating it against a formal XML schema along the way, there's no way to ensure that it contains the right data. You cannot ensure that an element that the client is planning to do a slick e4x whammy on actually exists. So you have to write all sorts of conditional code in the client to defend against this. And when you are under the gun, trying to get your app out the door, and you're mind-melding with your server-side counterpart throwing in this element dropping that parameter, etc, it rarely gets documented.
By wrapping your xml in a SmartVO, you at least encode your expectations of this XML fragment in one place, and not scattered throughout the app. So when the ad-hoc XML changes as it inevitably will, you have one place to go to adjust your client-side code.
If you notice in the SmartVO example, you're still perfectly able to wield all your e4x magic in the VO, but to the rest of your application, you are dealing with a typed object. This is good because your compiler can now catch all sorts of problems that it can't with bare XML.
If you had a Smart VO and wanted to use its XML structure or a fragment thereof to populate a tree, you could always expose a XML typed getter/setter that gets the fragment and you use that as your dataprovider.
But when you pass bare XML around you're going to end up finding e4x spread all through your app, and that's a nightmare to fix when your schema changes.
That said, there are still places where dealing with XML in the view is the right approach, though not as a value object crossing tiers. On my last project, I built a 'script composer' allowed you to create and maintain TCL scripts in either a text editor or a tree where you could drag and drop various tokens like loops and such. You could go back and forth between the tree and text representations. In the tree view, the entire TCL program was represented in an XML dataprovider. I didn't load the XML, though. I loaded TCL script and parsed it internally into XML and then back; sending TCL back to the server where it was simply saved to a file. I had to build a strict parser that was able to ensure that the XML and text were always valid TCL and in sync.
See an example of a 'Smart VO' here: http://forums.puremvc.org/index.php?topic=1293.msg5973#msg5973