The big fish swallow the little fish: Adobe's FXG and MicroSoft's OOXML

By Rick Jelliffe
May 5, 2009 | Comments: 3

Adobe's FXG seems 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.

A reader sent me the following heads-up:

This is pretty funny on a number of levels... on one hand it helps to illustrate how much of the Office formats conflict was driven by hatred of Microsoft. On the other hand, it shows what kind of manana, manana response Microsoft might have taken if an international standard wasn't getting shoved up their ass.

http://blogs.adobe.com/jnack/2009/05/some_thoughts_about_psd.html

The blog my reader reffed are comments from Adobe's John Nack on a great dummy spit found in some comments on some open source code hosted at Google's code site. Here is a taster:

 
// Earlier, I tried to get a hold of the latest 
// specs for the PSD file format. To do this,
// I had to apply to them for permission to 
// apply to them to have them consider sending
// me this sacred tome. This would have 
// involved faxing them a copy of some document or
// other, probably signed in blood. I can only 
// imagine that they make this process so
// difficult because they are intensely ashamed 
// of having created this abomination. I
// was naturally not gullible enough to go 
// through with this procedure, but if I had done
// so, I would have printed out every single page 
// of the spec, and set them all on fire.
// Were it within my power, I would gather every 
// single copy of those specs, and launch
// them on a spaceship directly into the sun.
 

As my reader notes, the parallels with OOXML are really strong. My long-standing view is that all market-dominating interface technologies should be RANZ-z open standards which are undergoing an ongoing QA/QC process from a working standards process where the significant stakeholders are consulted or participate and with the appropriate IP issues cleared up: Adobe is clearly a market leader in these areas, so I would expect that PSD/AI/etc exactly fits into this situation.

Now there is another parallel with OOXML: rather than "what about ODF?" we have "what about SVG?". Both ODF and SVG are open standards that have a lot of goodwill and buy-in, and both have been designed with the more 'optimalist' mentality; surely we should go with the existing standard?

However, both ODF and SVG were strongly influenced by their initial basic technical decisions. In the case of SVG, this meant that the page geometry followed a more PostScript-friendly model (IIRC Adobe and IBM were champions for this), which was ultimately unacceptable for MicroSoft (who had proposed VML) who withdrew from the SVG effort: VML was adopted by the early 2000's generation of MS applications and is part of the OOXML Transitional schemas, but has been superceded by DrawingML which is much neater.

While you might think from some Adobe comments that FXG is built on top of SVG, in fact it diverts from SVG: according to the FGX spec the relationship between FGX and SVG really is:

FXG does borrow from SVG whenever possible.

So FGX uses a subset of the SVG Path but allows filters at a higher level. Mark Anders has a blog entry about a prototype that did attempt to use SVG, and comments on why SVG wasn't up to the job of preserving/implementing some of the specific capabilities required by Flash. (According to him that is. I am not taking any side that FGX is necessary or good or bad or unnecessary compared to SVG.)

Now this is not the first time we have seen SVG-alikes: indeed, ODF uses a dialect of SVG which has markup and a namespace for things that the participating ODF stakeholders required that are not in SVG. I have put in a request for ODF Next-Gen to move to supporting real SVG-Tiny 1.n, and a liaison comment from a W3C SVG WG member has made the friendly offer for the SVG Working Group to work with the ODF TC to look at how to align ODF and SVG better, which I think everyone can agree would be a good thing.

However, the differences between SVG and the ODF faux SVG are really quite small. I think the ODF TC handled things really intellegently by putting their dialect in its own namespace: the purpose of namespaces is clarity after all. FGX looks like quite a different slicing of the cake than SVG, from a casual observation.

So, is FXG a good thing to become a standard?

Well, my take (at this early stage of the game) is along the following lines:

  • All market-dominating interface technologies should be QA-ed, RAND-z standards. So it would be good to have this in the standards sausage factory (though that is not to say that FXG needs to be a full International Standard: a Technical Report has much less onerous requirements and opportunities for hobby-horse fiddles) even though we presumably would decide to mandate SVG Tiny for our public data.
  • I think FXG needs to be a ZIP format that also allows a basic set of vanilla standard media and metadata parts. See ISO ODF or ISO OOXML or even Adobe MARS and Microsoft XPS. And one of these accepted media types should be SVG Tiny (even if a client just converts it to FXG as best it can on opening.) The format should be useful for a broad range of graphics applications: the Adobe range might be the kernel but not the hull.
  • The goal of getting a common XML-based file format for the range of Adobe products (i.e. replacing .PSD and .AI) with an emphasis on fidelity may be regarded as a useful tactic to reach the much longer-term strategic goal of universal file formats. People sometimes make an analogy of file formats and electrical plugs. But electrical plugs only have three prongs (in my country, usually): a file format is a plug with potentially thousands of prongs!
  • That there are difficulties by several groups in implementing SVG, even the ones who seem to have good will, may suggest that there is some kind of underlying parameterization needed for SVG. Or some better kind of macro or higher-level manipulation-declaration-library facilities. [I am not saying this is necessarily so: if the cap does not fit, don't wear it! ] SVG has already had to profile itself into SVG Tiny. And the advent of OpenVG may suggest that some kind of layered or stacked approach could be developing too.


My working model is that we need to think of the de-proprietarization of market-dominating technologies in the intensely pragmatic model of a sequence of bigger fish swallowing smaller fish: a sequence of consolidation of dialects, modularization of parts, then adoption into pluralistic frameworks and Adaptability Standards, allowing user selection of winning mini-technologies. Each stage of which will take at least a major software release cycle.

I think the idea that standardization means supplanting all existing technologies with a single new one in one step, where even companies whose requirements/capabilities were objectively not met by the new standard are somehow expected or required to embrace the defective standard, is impractical verging on pipedreaming. And definitely a pipedream where the prominent stakeholders consider the technology underlying the formats as their crown jewels.

It is important for governments and activists and stakeholders to keep the pressure on vendors to engage in calm de-proprietarization efforts in affable standards bodies, and not to regard standardization as a firefighting activity. I worry, for example, that after the acceptance of ODF and OOXML at ISO, participation rates will lapse, as if there were no more work to be done.

To put it another way, even if you don't think that the big fish swallowing the small fish model of standards development (by cycles of consolidation, modularization, and selection, converging towards universally acceptable standard formats) it is in fact what we have to deal with in some important cases. So the trick is figuring out how to get effective participation to fatten up the smaller fish for the next bigger fish.


You might also be interested in:

3 Comments

Hi Rick, I posted a response here to clarify what we were trying to accomplish with FXG.

Mark

Mark: Thanks for the additional information. (I am a big fan of exposing native graphics APIs as XML, e.g. SwiXML.)

I (and my reader) took my angle from (Adobe's) John Nack's comments like Wouldn't it be better if all apps could read/write just one common interchange format?

So really what FXG is about is not about interchange formats at all...It is about how to generate Flash-driving documents from Photoshop and other Adobe applications?

Also, check out Degrafa. It's an open source project licensed under MIT that pulls concepts from SVG, XAML and others to create a declarative graphics framework that is very powerful. You should be able to use it within FXG as well. http://www.degrafa.org

News Topics

Recommended for You

Got a Question?