My Favorite Thing About Flash Moving To an XML Format (XFL)? Let Me Count the Ways….


Though not 100% official, John Nack recently blogged that according to Colin Moock, the next gen of the FLA file may actually not be the binary blob that we have all come to know and love/loathe. How many of you have had a FLA take a dump and end up unusable, corrupt or somehow otherwise messed up beyond repair? I’m sure a few of you know what I am talking about. Beyond this reason, an editable, XML based file certainly has some advantages. Let’s bluesky here… what am I excited about with this?

  • Speed up repetitive timeline operations – Blam. You have a pile of similiar actions/keyframes you need to pound out? Don’t want to write the AS to Tween or do something else via code? Need to share the file with animators later that don’t likey the codey? Why not fire up Flex’s editor and regex till your hearts desire and rework or add to that XML file with a few surgical search and replaces. Might actually get me to use Flex less often for some things, especially if Flash added a “Markup View” where you could directly edit the XML in Flash’s IDE.
  • Share/reuse parts of files - Client Logos, Nav bars, commonly used assets, etc… I could see having a few snippets of XML in my “frequently used bits” folder that get copied/pasted into new Flash files on project starts.
  • Proper versioning support – Subversion doesn’t properly support binary file formats, so running diffs on two FLA files just doesn’t have the same effect that you get with AS or MXML files. A non-binary file format solves this neatly. Now, since XFL looks to be some sort of ZIP file, etc… there could be some diceyness here, but ooh lala, my IT guy is liking this, I can tell.
  • Authoring with a ton of different apps - Don’t like the Flash IDE? Make your own. Use Visual Studio, Eclipse… write one with Actionscript. After all, if you are simply editing/writing XML, why not?
  • Replacing assets sound like a snap – Yes, you can use Flash’s library pallette and run one by one updates/linkage adjustments, etc… But if you can simply drag files into a XFL archive and reopen that file in Flash to see all your assets updated, I say let’s do it! Sounds way way faster!

I’m sure I could spend a few more minutes and come up with a half dozen more reasons, but enough… what are you thinking? Do you see the possibilities? What’s on your mind about this development/news?

Posted on


3 comments

  1. Theo Mar 12

    Although I agree with you that moving to an XML-based file format is a really good thing, I think that you will be disappointed when it finally arrives. As far as I have understood it the file format will actually be a zip archive containing an XML and pictures etc. so Subversion will still have no idea how to diff it.

    And looking at Apple’s applications, most of which use a file format that is similar to what XFL seems to be except that they are not zip archives but folders, I would say that being able to diff things would be very unlikely. XML is quite undiff’able to start with, and when it comes to XML generated by applications it gets really ugly. Since diff works on lines and XML doesn’t care about lines but hierarchy, you have to be lucky, or hand code your XML to even be able to use diff.

    MXML usually works fine when diff’ing because the hierarchy is simple, and things tend to change within the same hierarchial level.

    That aside, I wholeheartedly agree that XFL seems to be a really good thing, just being able (as Moock mentions in his post) to unzip the file, change the images and re-zip it without even opening the Flash behemoth would be great.

  2. Keith Peters Mar 12

    As I understand it, you’ll have a choice between straight xml or a zip file format. If formatted correctly, and consistently, I don’t see why it would be hard to diff.

  3. John Dowdell Mar 12

    “Though not 100% official….”

    Yes, you’re right, sorry about that. Richard has a blog, as well as the DevNet publishing system, and I’m not sure why a significant feature change appeared first in a non-staff blog. (John Nack is in a different product group within the same business unit.)

    I can’t say anything until the relevant stakeholder within Adobe actually goes on the record. It’s a convoluted presentation right now.

    jd/adobe

Leave a reply