Designing the Data

We stand exactly at the intersection of these two historic forces: a pretty web and a smart web. Lucky us ”it is a good place to be. Flash is designed to make attractive graphics. Server software was built to do data processing. We must link them.

As you design the data object, you decide the nature of the project, now and in the future. Your creative decisions will make the difference between a flexible, useful, lively site and a disposable web presence that is quickly outdated and must be recreated.

Consider the following issues as you design your data object.

Many Browsers

Your XML should describe the content in a way that is useful on many platforms. Your ActionScript software will interpret the content to create an animated Flash display. But most publishers want to have alternate access for those who won't or can't install the required plugin. So you or someone else may create a script (perhaps an XSL file) that transforms the XML data into HTML, WML, or some other format. Even if this is not yet planned, consider now what information the transformation will require. Clearly you will want to avoid presentation information that limits the platform, for instance, expressing some values in terms meaningful only in ActionScript.

Some platform-dependent data may be inevitable, despite your best efforts to abstract it. As in the following example, you should supply alternative data for other platforms.

Example

You have been asked to create a jukebox application for a music site. The songs exist as music videos in SWF format. XML is used to create a catalogue of music and artists and it locates each SWF music video. If your XML format includes a URL for an MP3 file as well as the SWF file, you will be creating the backbone for an alternate no-Flash jukebox. The people responsible for this site will have to maintain only a single set of XML files to support both the Flash jukebox and the HTML/MP3 version.

It isn't trivial: As of this writing, for example, some mobile devices can display simple HTML and can play MP3s. But there is no Flash plugin available. You may not care about this audience ”they aren't Flash folk. But your client probably does.

Many Users

The objects you manipulate will exist in many states. The display the public sees is one view of your data. Since it is how your organization markets its product, it rightfully is considered extremely important. But by considering the other people who will touch this data, a designer can create a sturdy and useful object that documents its own life cycle.

Example

Your client wants to sell college-logo sportswear. Your job is to build the Flash-based storefront. When designing the XML object that represents each entry in the catalogue, you think in terms of the display you want to present to the customer: a photograph of the sweatshirt, ad copy, perhaps an animated mascot, and so on. Eventually you add elements to enable the shop ping process, SKU numbers , prices, sizes, maybe even stock counts. But when you think about it, you realize that more is demanded of this page. The marketing manager must approve a catalog item before it goes live. The licensing college must sign off on any page in which their mascot or logo is displayed. These initials should be right there in the XML, at least in some stage of its life cycle. Model releases, authoring information, expiration schedules, and marketing effectivity data all might be part of this item, depending on who is looking at it and when. You can design an XML object that describes as fully as possible the way this item is seen throughout your client's organization. The happy result of this would be improved work flow and a faster, more responsive organization. This is not to say that all these elements would be present in any XML presentation. No user would want to see all these things. But the data design should be able to encompass any of them.

By the way, it is quixotic to try to anticipate every use to which your XML object might be put. Don't worry. The X in XML stands for eXtensible. New elements can be added later to your design, both globally or as a special extension.

Industry Standards

Before starting the big job of designing a sturdy data object, consider this: Your client is a member of a community. In most communities, you will not be the first to try to apply XML solutions to the common problems. There may be a committee-driven or de facto standard already in place. By building on such a standard, you will put your client in the market, not attempt to build a private market.

Example

You have been hired by a large real estate broker to provide a slick web browser for their real estate database. Assuming that their data is not in XML form, you will need to create an XML vocabulary for their server to communicate with your Flash browser. You must think through the data requirements and carefully develop a data object that will support all the features you want, now and in the future.

Or you can do some research and discover that this job has already been done. RELML, the Real Estate Listing Markup Language, is gathering industry support. By adopting this as your data format, instead of developing your own, you collect all these advantages:

• You have saved considerable work in designing and defining the data.

• You may save more work if you license existing RELML middleware.

• You have rich sets of test data.

• Other software ”browsers or bots ”can easily shop at your client's site.

• Your client can expose listings from other databases.

• A great deal of your development work can be reused on other real estate projects.