Flash moving to an XML-based authoring format

Well, I guess the cat is scratching its way out of the bag: as noted Flash author and developer Colin Moock reports on his blog, the Flash authoring tool is moving away from its binary FLA authoring format (undocumented & unreadable to the outside world) and towards an XML-based format.  Yeah!

Why the excitement?  I’ll admit, this seems like a pretty arcane subject, but the possible ramifications for workflow are great.  Colin writes,

Historically, interchanging source with the Flash authoring tool has been virtually impossible for third-party software because the specification for .fla has never been public… [Now, however,] in theory you might one day edit the images of an XFL file directly in Photoshop without disturbing the timeline information also contained in that file. Or you might be able to import a page from a word processing document into a Flash presentation.

I should add the obligatory caveat that plans are subject to change, none of this may happen, void where prohibited, professional driver on a closed course, etc.  Even so, I find the direction really exciting.

Back in 1999, long before I came to work here, I started lobbying my contacts at Macromedia and Adobe to create something I called the "Flash Interchange Format"–some XML representation of at least the basics of an animation (object name, position, scale, etc.) so that I could use Flash and After Effects together.  Unfortunately Flash remained locked to the inscrutable FLA format.  We did devise an XML interchange format that let LiveMotion and After Effects talk, and Dr. Woohoo has done terrific work enabling Flash and AE to exchange data, yet the tools continue to lack an out-of-the-box solution.

Now, however, I hear the sounds of a big door opening, and it’s a welcome sound indeed.

0 thoughts on “Flash moving to an XML-based authoring format

  1. Interesting.
    This adds an even greater level of control between layout, design and ‘business’ logic.
    Presumably this is in some way influenced by Flex and AIR?

  2. This is definitely a big deal, but I hope Adobe realizes how vital a command line compiler is to making this reach its potential. With a command line compiler the entire designer-developer workflow becomes automatable so that one designer can be updating images and other assets while another updates animations and motion and the developer cranks out code. Either through an Ant task or some continuous integration tool you can then compile the assets SWFs that the Flex app loads for styling, etc.
    If executed correctly this could be really huge.

  3. Compound document stored in zip file, using XML: not a friend of source control. I would also suggest/hope that it be possible to have this resource expanded on the filesystem to work with native tools (Flash CS4) and command-line tools (e.g. build and svn). Subversion integration within the Flash CS4 IDE sounds like a good idea, while Adobe is at it. -Sean

  4. its a chance for having a stable flash plugin on unix. do opensource the specification and external devels will care about writing a gnu stack. the closed source flash plugin currectly really is a shame for your company

  5. This is awesome to hear! With this xml move and the adaptation for common backend languages, would this be a response to Silverlight?
    [I’m not on the Flash team, so I don’t want to speak out of turn. I’m passing along these comments to them, however, in case they want to supply more info. I will say that the idea of using XML to trade design assets is obviously nothing new, so I don’t think I’d characterize it as a response to Silverlight. –J.]

  6. This is indeed hopeful news. I did a lot of research to see if I could make an open source FLA reader. All I found was that FLA was a type of OLE file, similar in structure to Word and Excel files, but that everything else was impenetrable binary.
    [Yeah, we had a similar experience on Photoshop before the Adobe-MM deal went down. I asked a couple of our best guys to try to crack FLA, but no dice. Only the pair at MediaLab ever figured out how to do it, and they did a very limited conversion (bitmaps and layer names). –J.]
    If Adobe’s serious about having more powerful and open-source friendly development tools, getting rid of FLA files is a huge first step.

  7. Excellent – One of the last fortresses of Adobe non-extensibility is falling. For the better of flash customers and developers. Oh, the possibilities… really exciting.

  8. john, i have to give you credit. i think it was way back at agency.com that you were trying to start a petition (religion?) for an interchange format very much like xfl. you were clearly (8 years) ahead of your time 🙂 you must truly be thrilled!
    [Heh heh–yes indeed, Colin (good memory!). I always argued to folks at Macromedia and Adobe, “Look, I like some features in FreeHand and some in Illustrator, and I can use them together via EPS. Why can’t we have something like that for animation on the Web?” So yeah, I’m very excited. –J.]

  9. Not that I am saying its better overall, or even really aimed at the same market – but Silverlight has done this via XAML/C# since its very inception.

  10. XFL is so good as we could dream about it.
    Now, we know about the brand new Switchboard technology on Adobe Labs, which aimed to allow AIR developers to integrate Creative Suite tools.
    XFL + Switchboard… Unpredictable Result! Flash on the Flash. The only thing I can wish here is support for custom tags in XML, or just extensibility.

  11. A big issue with many designers I know is the enjoyment of InDesign for its ease of use and layout– but the inability to convert that to the web.
    XFL seems like it could really open doors. Indesign seems ready for interactivity, but there is no documentation out there. This could be the springboard for print deisgners getting ready to enter the web design arena (albeit only the flash portion).

Leave a Reply

Your email address will not be published. Required fields are marked *