In Part One we understood the need for XML. Just to reiterate, here are the reasons it exists in the video world:
- You can transfer more data types like metadata, keywords, notes, effects, transitions, retiming effects, and so on.
- Like EDL, it is human readable and machine readable without human supervision.
- It allows the users to define tags at will, which makes XML cool for many types of data transfers.
- It represents today’s data-driven internet model rather than the tape model which EDL was based on.
- XML can be added to other XML, pushed between non-XML data, and still retain their utility.
- XML makes it easy to program things like batch-renaming, etc., by working directly with the XML text.
- It can incorporate image sequences and special video/audio types. It can take any kind of innovation.
But you know there are negatives, right? Here they are:
- Since anyone can create their own tags, it’s like anyone can invent their own words in a language. Soon, people will stop understanding each other.
- In an EDL, a video is represented by V, audio for A or AA, and so on. In XML, the same thing occupies a lot more space. E.g., the sample EDL that we exported in Part One weighs in at 4 KB, while the XML version weighs in at 41 KB.
- Humans and computers don’t really mix. Even if a human creates a ‘tree-like’ structure for XML, a computer might not always operate that way. Ultimately, XML ‘disappoints’ both, by not being completely partial to either.
The basic structure of XML
An XML file usually begins by telling everyone what the file is:
<?xml version=”1.0″ encoding=”UTF-8″ ?>
This is just one big tag, which tells everyone which version of XML is being followed, and what encoding is used. E.g., you shouldn’t use Microsoft Word Rich Text format to edit your XML files or it won’t be readable by your video application.
The next thing, not mandatory (what is?) is the Document Type Declaration, which is the file’s way of announcing which document type it uses. If XML = language, then Document type = English, Russian, etc. This is how it looks like:
XMEML is the Final Cut Pro 7 XML document type. We’ll get to that in the next section. Finally, whatever content is written must be enclosed in an <xmeml> tag:
<xmeml> blah blah blah </xmeml>
This tells Final Cut Pro that this document is indeed its own. To learn more about XML tags specially created for Final Cut Pro, read the excellent introduction in the Final Cut Pro manual. Before we go on, here are a few advantages of using XML, in Apple’s own words:
For example, if you have 100 clips that all have “Koffee House” in the name, and you want to change the names to “Coffee House,” you can export the clips to Final Cut Pro XML, open the XML file in a text editing application, find “Koffee” and replace with “Coffee,” and then import the resulting XML file back into Final Cut Pro.
You may also want to use XML when working with text generators or superimposed graphics. For example: You have a sequence with hundreds of subtitle text generators, and you want to subtly change the color or position of each subtitle. Manually moving each subtitle in Final Cut Pro would be extremely time-consuming. Instead, you can export the sequence as XML and then find and replace all of the positional parameters or color settings at once.
These examples are only the beginning. You can also change clip In and Out points, change the order of clips in sequences, or modify effect parameters. The more you experiment, the more potential you will discover for modifying Final Cut Pro elements using XML.
The two types of Final Cut Pro XML
When FCP-X was released, Apple also changed the way it uses XML. There are good reasons for this. The most important is the fact that FCP-X defines data (your video, metadata, everything) in a totally new manner, and furthermore, it structures projects separately (into events and projects).
It’s almost similar to the difference between poetry and prose. A human might be able to read both, but try defining them, and you’ll soon step into a murky grey area.
To get a quick but thorough overview of why FCP-X is fundamentally different from FCP 7, read Philip Hodgetts’ excellent write-up.
Long story short, there are now two kinds of XML:
- FCP 7 XML, called XMEML, and
- FCP-X XML, called FCPXML
Here’s a comparison image of the two, one exported from Premiere Pro and the other from FCP-X:
As you can clearly see, the Document declaration spells out clearly that these are two different kinds of XML documents, with their own words and structure. They are as different as English and Chinese, and translating between them is just as accurate as translating literature from English to Chinese and back. This is what I meant when I said XML is like a language, which, though developed to make life easier, actually makes it harder.
To get a complete and detailed overview of FCPXML, check out Apple’s PDF for developers. If you can find a way to weave magic with FCPXML, you might make yourself a lot of money.
Who else uses XML, and which versions are they?
You might be thinking: FCP 7 is almost dead, right? So why worry about XMEML?
The truth of the matter is, FCP 7 is still used in millions of systems around the world. Also, Adobe Premiere Pro still uses XMEML and calls it Final Cut Pro XML (notice there’s no version number). This is how I could export an XMEML even though I don’t have access to FCP 7.
Some of the software that supports XML are:
- Adobe Premiere Pro CC – XMEML
- Blackmagic Design DaVinci Resolve – FCPXML and XMEML
- Apple Motion – OZML (yet another version of XML)
- Autodesk Smoke – XMEML and FCPXML
- Avid Media Composer can only export XML using Filmscribe (no import capability), but in the Filmscribe XML format. Avid has its own AAF format for file interchange.
How bright is the future of XML?
Who knows? If Apple can change the Final Cut Pro XML format, then there are theoretically infinite number of XML formats. Look at the problem compounded:
- There is more than one version of XML itself.
- Then there are different document types like XMEML, FCP XML and so on.
- Each type has versions (look at the third lines in the above image).
It’s a catastrophe waiting to happen. The biggest stumbling block is that some applications like to import timelines but not effects or color information. What’s the point? Why should they ‘clean up somebody else’s mess’?
Which is why you’ll see many clamoring to read XML, but few caring to write it.
In today’s marketplace, you’ll find EDL, FCPXML and XMEML, and more. It’s just too chaotic to pin down any one format and declare it the winner. Some projects need the complexity of XML, others don’t. Some applications, like Adobe Premiere Pro and Resolve, support as many formats as it can – but that’s not a philosophy others subscribe to.
All said and done, XML is convenient sometimes, but not all the time. It has potential, but only if everyone agrees to use it one way – but knowing humans, that’s unlikely.
I think it’s a minor miracle XML exists and works as well as it does, and I’m thankful for that. Ask yourself: What would you do if you didn’t have it?