Have I got a deal for you! This new technology you’re going to put into your facility is not only going to save you money, it’s going to pay for itself with the new revenue it brings in!
How many times have you heard that? How often has it actually turned out to be true? I’m guessing that your answers are predictable.
The adage “if it sounds too good to be true, it probably is” tends to be reinforced on an almost daily basis. So, why are you still reading this? Was PT Barnum correct?
You’re probably still reading because you’re hopeful — optimistic, even. There are rare cases in which the reality meets or exceeds the promise, and it is those which make it worthwhile to sort through the noise of unfulfilled promises.
The first thing that will come to most peoples’ minds when they hear BXF is that it sounds like technology. It is, but in this case, the technology is not the exciting part — it’s what that technology can do to improve your workflow. Of course, you aren’t in the habit of changing workflow for its own sake — you’re looking for benefits. Are cost savings and promise of increased revenues realistic? Let’s dig a little deeper, and then let you be the judge.
The format was originally created to solve the mess that existed between traffic and automation systems. Literally hundreds of proprietary, batch-oriented interfaces littered the landscape, making interoperability between systems a serious challenge.
After the formation of the group within SMPTE that was tasked with developing BXF (the standard is officially known as SMPTE-2021), it became apparent that it made sense to get content distribution representatives involved. At a high level, the messaging needed to support the movement of content metadata as well as content movement instructions that seemed pretty similar, whether dealing with content within a facility or content needing to be obtained from outside sources.
So, the basic membership of the group developed into representatives of the following interests (primarily): traffic/automation, program management/listing services, content distribution and users.
The short answer is: many. However, there are some very specific areas that were targeted during the development of BXF as needing to be solved.
Much of the problem that has plagued the industry for decades has been that the manufacturers of each broadcast system found themselves having to reinvent interfaces each time they worked with another vendor. There was no standard, so anarchy reigned. While “custom” is nice for those who can afford it, it is often prohibitively expensive. In an increasingly lean market like broadcasting, the cost of “custom” often cannot be justified.
So, simply creating a single standard that vendors can write to is a quantum leap.
One of the real limitations of these traditional proprietary interfaces was that they were, without exception, batch in nature. What this means is that they were intended for a workflow in which System A does everything it needs, then hands the data “over the transom” to System B. At this point, System A washes its hands of any responsibility and moves on.
While that’s nice and simple if you’re the manufacturer of either of those systems, it doesn’t reflect the reality of the workflow in a broadcast facility. Workflows are rarely purely linear in nature — often steps are performed iteratively. Take the construction of a broadcast schedule, for instance. The traffic system at some point deems the schedule ready to publish to the automation system. Once this is done, that’s rarely the end of the story. Changes to the schedule are inevitable, and sometimes quite voluminous. With batch-oriented interfaces, there is no simple mechanism to enable messaging of those changes between systems. As a result, the changes must be accommodated outside of the interface using manual steps.
Building dynamic integration between systems, in effect removing the “transom” referenced earlier, allows those systems to mimic the actual workflow that exists. This means that broadcasters have systems that fit their natural workflow, rather than having to fit their workflow around those of the systems.
It would have been nice if we could have said that we were abandoning file-based exchanges altogether and going exclusively to a message-based architecture. However, as with most things, technological changes that are most effective are often accomplished by way of many small steps, rather than a single leap.
It was unrealistic to expect the wide variety and vintage of systems being used today to completely change their approach simply to accommodate BXF; therefore, it was decided to structure BXF in such a way that it could be used effectively in traditional file exchanges and in message exchanges.
In practice, the workflow that most broadcasters seem to prefer involves a combination of the two. Exchanges of data files make sense when a large volume of data must be sent at a specific time — for instance, when a log is deemed complete and ready for publication by a traffic system. However, messages make far more sense than files when smaller volumes of data are exchanged on an ad hoc basis.
It is possible that, as systems evolve, file-based BXF exchanges will become a thing of the past, and messages will be used for all data flow between systems. However, we are not currently at that point, and we won’t be for a while.
The traditional interfaces that BXF replaces were always computer-friendly, but human friendliness was not one of their attributes. The focus when many of these protocols were invented was on efficient machine-to-machine communications. Bandwidth and computing power was limited, meaning efficiency won out over readability. This is how we ended up with values encoded in binary coded decimal, hex or even pure binary. Even pure text values were expressed in arcane shorthand.
Some questioned the importance of human readability when we began the BXF effort, but the voice of the user community was loud and clear on this. They were tired of trying to open files in an effort to resolve problems only to be faced with a collection of data harder to decipher than a doctor’s handwriting!
The results were twofold. First, BXF was created using XML (eXtensible Markup Language), which imposed structure on the data and allowed for helpful annotation within the file itself. Second, great pains were taken to ensure that data values included in BXF were verbose. If the data value is meant to indicate that the spot is a “promo,” we use the value “promo.” This way, even a relatively non-technical person can open a BXF file and have a chance of reading it and perhaps even find the source of the problem that caused them to open the file in the first place.
As outlined in the previous section, XML was readily agreed on as the format that made sense for BXF. By its nature, XML is extensible.
Although great time and effort was spent on including everything that seemed necessary for effective communication among systems, the group acknowledged that there would be things that would inevitably be missed, and unanticipated industry requirements would arise after publication of the standard. For this reason, it was critical that extensibility be built into BXF. Failure to do so would result in a largely ineffective standard.
Extensibility is accommodated in two ways within BXF. The first and most straightforward way is via the nature of XML itself. Attributes and elements can be added to future versions of BXF without causing incompatibility. Applications that don’t understand new elements and attributes simply ignore them.
The second way in which extensibility is achieved within BXF is targeted at more specialized, short-term requirements for extensibility. “Private Information” elements and “##any” attributes can be found at virtually every level of the schema. These allow vendors to add in site- or system-specific elements and attributes to the base schema. This way, if there are things that BXF does not handle, but which are needed, vendors can still use the base BXF schema and simply add in the elements and/or attributes they need. If these private extensions develop into general requirements, they can then be added formally into a future version of BXF.
Part two will look at how BXF can save you money, and part three will look at how it can make you money.
For more information, visit www.harris.com and www.smpte.org.