« November 2008 | Main | July 2009 »

May 08, 2009

Thoughts on FXG Design and Motivation

Rick Jelliffe wrote about FXG on his blog where he both equates it to OOXML and asserts that it was designed as a replacement for the Adobe Photoshop PSD file format. You can read his post here. Since he references an earlier posting of mine about FXG, I thought I’d respond. Also, since his writeup was focused on Photoshop, I'm not going to assume knowledge of Flex or Flash

First, FXG was not designed to be the document format for any of our apps, and so was not meant to be “to PSD what OOXML is to .DOC: a re-factoring of a middle-aged binary format in XML with a focus on fidelity rather than elegance.” In fact its focus is not PSD or Photoshop or Illustrator at all. Likewise our main goal was not to create an XML based graphics interchange format like SVG.

The thing we set out to design, first and foremost, was “componentized graphics” for Flex, which is an open source framework for creating Flash-based content. This goal was responsible for most of the constraints we had to contend with. FXG is a well documented subset of this, so that tools could read and write these componentized graphics descriptions without having to understand Flex, Flash or ActionScript, which is the programming language supported by the Flash Player.

So the origins and goals of what we did are not really comparable with how Microsoft approached OOXML. What follows will also explain why it’s conceptually different than SVG. Here is some background as to how we approached the problem.

Flex is an ActionScript-based framework for building applications. It provides a set of ActionScript components that are used to create user interface, and it is easy to add new ones. Historically, Flex gives you things like Buttons and Datagrids for building UI. Flex also has a nice XML-based language called MXML that defines simple rules for how an ActionScript object maps into XML and is useful for defining how objects are to be instantiated and parented. The rules are really simple. If you have an object, its name becomes the name of the tag. Properties on the object become attributes on the tag. Metadata applied to a object defines how it can contain other objects. Everything is case sensitive.

So if you have an Application object that has a Button , rather than writing a bunch of procedural code to say:

var app: Application = new Application();
app.minWidth = 1024;
app.minHeight = 768;
var button: Button = new Button();
button.x = 31;
button.y = 27;
button.label = "Hello";
app.addElement(button);

You can more easily write:

<?xml version="1.0" encoding="utf-8"?>
<Application xmlns="http://ns.adobe.com/mxml/2009" minWidth="1024" minHeight="768">
    <Button x="31" y="27" label="Hello!"/>
</Application>

This has lots of benefits but it’s important to note that the code is equivalent. You could write it either way. Using XML as the basis for the language has the nice property that it makes it much easier to provide graphical design tools to author and edit the files since the code is declarative rather than procedural.

In looking at what we had accomplished with Flex, one thing we realized is that, while it was easy to build apps out of buttons and textinputs and datagrids, if you wanted to use a line or an ellipse, it was much harder. Flex had no defined way of using graphics as building blocks. You HAD to write procedural code.

Since Flash is, after all, all about graphics, we wanted to extend Flex to make it as easy to build things using graphics as it is to do so using datagrids and buttons. So what we did was to create a set of ActionScript objects that represented all of the graphics that Flash could do, and to design them so that, when they got mapped into an XML format, they looked nice.

It is important to emphasize that the design process for Flex and its XML format is different from how one typically creates XML based formats. With XML, you typically lead by thinking about schema and the semantics of how it should be interpreted. Flex does not have a schema. It has ActionScript objects that imply a schema but everyone can and does create new ones. So here, you think about ActionScript objects AND how they map into XML using the rules of MXML.

To design our Flex graphics, we followed the same guidelines that we follow for all of our additions to the Flex Framework. This is what the prototype I described here, and that Rick references was about. Our design guidelines, like with Java and other systems, have conventions that say, for example, that class names begin with an uppercase letter, and methods start with lowercase. In my prototype, my classes were inconsistent. I did have things like:

public class LinearGradient

Which are fine according to our guidelines, but I also had things like:

public class g
public class svg

Which were not. Likewise, we specify that property names are to be descriptive. Therefore:

LinearGradient.gradientUnits

Was just fine, while:

path.d

Was just wrong. So we thought it would be bad to have the graphics classes be completely inconsistent with everything else in the system. Consistency and elegance was important to us. So in the design of our objects, we followed our established standards.

Once we designed the graphics objects, the XML format was, in essence, designed for us, by the rules of how MXML maps objects to XML. Having graphics as part of Flex and MXML gave us a number of nice benefits. MXML has syntax (like HTML) for adding event handlers to objects. So, for example, if you wanted to take an Ellipse and handle click events, you could easily do it like this:

<Ellipse x=”10” y=”10” width=”100” height=”50” click=”onEllipseClick()” />

You can also do things like have databinding expressions to programmatically bind one variable to another, such as:

<Ellipse x=”{mouseX}” y=”{mouseY}” width=”100” height=”50” />

After doing this work to extend Flex with graphics objects and the resulting XML format, we realized 2 things:

  1. It would be great if graphical tools such as Photoshop, Illustrator and 3rd party tools could read and write the XML format so that you could create graphics in those tools and easily bring them into Flex.
  2. A lot of the things that are legal in Flex MXML and that a developer might do, such as adding databinding expressions or event handlers to a graphics element or (gasp) intermixing a button, datagrid or some other component with the graphics markup, would make it impossible for tools that don’t understand Flash, Flex or ActionScript to reliably work with this markup.

As a result, we decided to create the FXG format, which is a subset of MXML that includes only graphics tags. It removes all of the developer-oriented syntax such as databinding and event handlers, and it is also rigorously defined as an interchange format, so that the behavior of the graphical elements is defined as is the rendering model. We did this by focusing on schema and semantics as the first priority, but most importantly, keeping in mind the corresponding runtime objects in Flex.

So unlike SVG, our goal was not that FXG would be an interchange format to be sent to a client machine for runtime interpretation, even though this is possible and sometimes even desirable to do. Rather, FXG was designed as an exchange format between tools that understand graphics, like Photoshop, Illustrator, or other 3rd party ones, and tools that understand Flex and MXML.

I hope this puts a bit more context on what we did and why.

Posted by Mark Anders at 04:51 PM | Comments (4)