You would be surprised to see just how many steps that life cycle can be broken into. The success of this optimistic effort remains to be realized.

  But AdsML also presents a picture of how technology works and about the people, cultures, politics and economics of various groups that create a context that pushes something abstract down one path instead of another, with what will eventually yield material consequences yet unforeseen.

  In this issue, we'll break down the bulky stack of AdsML public documents (and some unreleased) to describe the standard: the AdsML Framework and the goals of the AdsML Consortium a group perhaps best described as "independent, incorporated in GermanyC9 supported by NAA and Ifra as sponsors, and by Associated Newspapers [of Great Britain], Agfa and Time Inc. as strategic partners," according to Sue Fine, manager for technology communication for the NAA and a press officer for the consortium.

  The Framework is conceived of in phases.

  Technology of AdsML 1.0

  AdsML is defined primarily as an XML-based business tool that facilitates business and technical cooperation in the so-called advertising supply chain. Technically, it is a data exchange mechanism that supports "trading partners" as they swap data throughout the "advertising and advertisement" life cycle across all media. Those events might include everything from campaign planning, determining available inventory, booking, delivery, publication or broadcasting, performance reporting, invoicing, payments, claims processing and account reconciliation.

  The consortium's plan is to make AdsML flexible enough to adapt to changing business demands and technology, which could mean that its end stage of development is situated somewhere just this side of infinity, global warming notwithstanding. It will be open source, royalty free and technology-independent, and will have specific requirements for moving data around between "trading partners," the latter two characteristics being arguments against trying to adapt older standards - proprietary or vendor-defined formats - to a broader range of capabilities and needs.

  When the consortium released the AdsML specifications in May 2004, the consortium did not have a clear enough idea of the extent to which "advertising specific" features would eventually be needed, thus precluding off-the-shelf use of XML. Furthermore, existing XML-based standardshad not satisfactorily addressed the need to have "clean" solutions to identified problems, such as "certain types of interactions between application system functionality and a generic exchange process."In a somewhat dubious use of logic to lobby for a new standard, the document also argues that for the most part, none of the pre-existing standards had been widely enough adapted that "not to use them would [not] be an obvious error."
Still, at the consortium meeting last March, timed to coincide with NEXPO, serious questions were raised about the necessity of a new exchange standard, given the relative proliferation that already exists with BizTalk, ebXML, EDI (Electronic Data Interchange), SOAP and CREST (these last two sounding as if they have more to do with personal hygiene than advertising data exchange). But more about that in part two of our story.

  Key Concepts

  AdsML initially addressed 11 key concepts, which we have boiled down to the following paragraphs:

  Purpose: Its business and technical purpose is to enable efficient electronic exchange of advertisement-related information throughout the complete advertising life cycle.

  Adaptability: It will accommodate many different existing standards and formats already in use, including advertising-specific XML standards (NAA's CREST, IDEAlliance's SpaceXML and Ifra's AdConnexion), as well as non-XML EDI standards and comma-delimited formats.

  Trading partners: To use AdsML, both "trading partners" must agree on the types of information and the standards and formats each will use, and these must be recorded in a "Process Partnership Agreement (PPA)," which is part of both the AdsML envelope, and a "Trading Partner Agreement." The latter might exist only informally, but the PPA must be recorded, since it is the means by which AdsML processors at each end of a transaction control interactions between systems. This interaction, or choreography, is based on a send and query/response model.

  And now, the envelope, please: A central AdsML multimedia envelope defines the inclusive packaging mechanism and supporting technology for conveying data. Based on the PPA, each envelope will have a predetermined set of responses and each item in the envelope will have its own identifying sets of responses. It is an AdsML schema consisting of header and body. One envelope can carry many different messages, each of which can exist in a different format and which need not be related to the same advertisement, publisher or aggregatorThe envelope, like those we use every day in posted mail, needs to understand neither the messages it contains nor their formats. It simply has to contain them and understand their XML metadata for them to accomplish their task.

  Its header contains all the information necessary for routing, processing and responding to the AdsML message, with the body containing the actual advertising content: the AdsML items, themselves encoded as described above, in a variety of formats and standards. But to make it work, the parties involved need to have already agreed on the format they'll use to exchange information, and the format has to be one of those that can be placed inside an XML document. And an AdsML processor has to be situated at both the sending and receiving end of the process. Even though it has multiple item-level applications, each organization is likely to have only one AdsML processor, which creates, transmits, receives and responds to the administrative and technical messages in the metadata surrounding the envelope

  At a second level, the items in the envelope, which are also wrapped in metadata, have a more complex interaction with the organization's various software applications, completely unbeknownst to the AdsML processor, which simply treats the items equally as "black boxes." There is more back-and-forth communication at this level, since internal organizational rules govern the circumstances under which messages are "sent, acknowledged, queried, refused, altered, etc."Each envelope is sent by a single sender to a single recipient and vaporizes, more or less, once the items are removed. This is called a direct exchange.

  But some items will need to be repackaged, or they can be stored at an intermediary site before being forwarded to another with no intervening processing Others, however, might need to be processed and repackaged before continuing their trip to a series of other trading partners, and so might be packaged in a series of envelopes "during the course of its life." This is called an indirect exchange .The item will simply be repackaged and join items from other envelopes that are destined for another recipient, say, for example, passing from buyer to buyer's rep to seller's rep to seller.
All along the way, the AdsML processors are sending responses indicating the acceptability of the transmission. It's the familiar "ack" (acknowledgement) and "err" (error in structure or syntax) messages, as well as notification that something in the envelope violated the process agreement between sender and recipient.

  Advertising Component Interactions and the Advertising Standards Matrix: The types of information (or business messages, hitherto referenced as items) and standards that trading partners can use are defined by two AdsML elements: the Advertising Component Interactions and the Advertising Standards Matrix.

  The Advertising Standards Matrix will be the part of AdsML in which the allowed standards and formats are listed. It includes information about what kind of standard or format is being used, which media (print, online, broadcast, SMS, etc.) the standard or format supports, and the classes of advertising for which it is being used (display, classified, insert). It also indicates whether the format has been, in the words of the consortium, "'blessed' by any associations or standardization bodies, and if so, which ones."

  Further on, we find that should the matrix show that two different formats are available for a particular use, say one that is a publicly available international standard and another that is proprietary and less widely used, users can make the choice about which to use (probably the first in this instance). This led me to envision a possible context in which companies join the consortium to make sure their standard or format is "blessed," and in which the whole idea gains a kind of internal momentum leading to a virtual requirement for suppliers to participate.

  The consortium believes that the matrix is a work in progress that will evolve over time to help the industry identify places in the advertising supply chain where there are either no standards or multiple standards. The latter situation could lead in the future to convergence into a single standard: Existing standards will be assessed for their ability to represent and transport data required by business processes against the analysis criteria defined by the consortium.

  Benefits: The evolving matrix is part of the "long-term vision of AdsML," and as the information is collected and collated, it will find its way into future releases of AdsML. Another part of that vision is that new systems will be built with AdsML conformance in mind, either at "core" or "enhanced" levels, depending on particular circumstances.
But in particular, the working group saw as one of the key benefits of AdsML the ability to "provide a 'higher level' common model that identifies key components and phases of the advertising life cycle while remaining above the workflow level," which, in turn, gives AdsML users "a reference point for locating and understanding their own business in the context of 'the big picture' background of the whole advertising life cycle," as well as the data and processes they need to support business development and integration. A huge part of this effort in the early stages was foundational - creating charters first, and then a series of other conceptual documents - a shared glossary, controlled vocabularies, specifications, schemas and requirements.

  The AdsML message-handling strategy is designed to replace the need to do point-to-point integration between applications with the single AdsML interface, where those interactions are defined in the process agreement. Even when a newspaper adds or changes systems in its advertising department, the AdsML interface is intended to be flexible enough to expand by simply adding a new agreement.
The AdsML envelope also is designed to achieve several goals. Processes can be automated, existing technical and infrastructure investments remain viable, and the industry gains a common interface to facilitate systems integrations.

  The consortium chose XML as the foundation of AdsML because of its "extensibility, self-definition and application independence." It allows backward compatibility and can describe the structure and meaning of data content, as well as validate the document's conformance to ensure that the right data gets to the right place at the right time. That also enhances the likelihood that the data will be reliable and makes it easier to catch problems sooner.

  The consortium also tapped into XML's extensibility in terms of the information that can be carried inside the envelope. The document's authors offer the following example:

  I must specify in the metadata that I am sending, for example, an insertion order or an invoice, and I must specify the standard or format I'm using, say AdConnexion. These would appear in a list of values or in a "controlled vocabulary" in AdsML-ese that my trading partner and I have agreed upon. We can restrict this list or we can agree to extend the controlled vocabulary to accommodate the specific terms we find useful, such as "OurPrivateXMLFormat."

  The idea behind this extensible mechanism is that each organization will be able to maintain its own lists of allowed values and change them independent of the pace of change at which AdsML upgrades occur. Controlled vocabularies in AdsML are implemented "using some of the built-in XML Schema capabilities," making it possible to use an off-the-shelf XML schema processor instead of writing custom code.

  The only catch is that we must agree that we will both have the terms we'll be using specified in our process agreement, although the consortium allows that it would be theoretically possible, though practically unworkable, to maintain a master copy of each controlled vocabulary, which would be referenced by every AdsML implementation and make any changes to it instantly available to every installed site.
Technology of Phase II

  Phase I of the work of the AdsML Consortium was a complete analysis of the parties, workflows and kinds of messages suitable for XML. This effort did not, in itself, solve any business problems. Early on, Phase II of the AdsML Framework was conceived of by the consortium as the aforementioned matrix of existing standards and interfaces that provide the gossamer software connections between any two machines in the advertising supply chain. When completed, it would yield a product that would satisfy anyone's deepest desire for order: We know what we have and from there, we can see what we need to create. Tony Stewart, chairman of the AdsML Technical Working Group, said the response to this was initially "gung ho!"

  To obtain all the information required to complete this necessarily collaborative project, the consortium posted a vendor questionnaire on its Web site, presumably following the dictum, "If you build it, they will come." What happened in Hollywood was not replicated in the consortium's field of dreams, however. Only eight responses crossed Stewart's desk - and some of those were from publishers. (In addition to his role at the AdsML consortium, Stewart is director of consulting at RivCom, which he describes as a vendor-neutral organization with experience in the development and application of XML standards. RivCom has also worked with media clients, including News International, The Daily Telegraph and Associated Newspapers.) No self-respecting standards developer would consider such a meager response sufficient to sanction a document with aspirations of making a contribution to the general well-being of the industry. Of the eight responses, half "focused on what they wanted us to create," Stewart said. Out of this experience, he said, the consortium decided to pursue another path.

  Technology of Phase II:

  Reconsidering an Earlier Concept

  In the summer of 2004, the consortium made the project public at Publish Asia, held in Kuala Lumpur, Malaysia, and organized by Ifra Asia. In a statement, the consortium noted that the group was committed to making the standards "as inclusive as possible, able to embrace and enhance existing standards, not replace them."
But even before July's Publish Asia in Kuala Lumpur and October's Ifra Expo in Darmstadt, the focus of Phase II seemed to broaden beyond the matrix to encompass something members of the consortium and others seemed to be pushing toward, something they could take home and use. Stewart said that work on Phase II began much earlier than any of these meetings - in November 2003, even before 1.0 was released, but plans were made public in June 2004 at NEXPO.

  By early August 2004, the consortium had a draft of an AdsML E-Commerce Overview and a Phase II Overview. While neither document was available on the group's Web site at the time this story was written, they are both available upon special request, as is a public draft of another that sets out the technical requirements regarding each of five components of the AdsML Framework: a set of business models and XML message format; a set of guidelines, recommendations and requirements describing when and how to use existing content and metadata standards; another set that addresses identified deficiencies and overlaps in the ability of existing content and metadata standards (which sounds very much like the matrix); and a definition of AdsML conformance, along with a mechanism for establishing who is and who isn't conforming.

  In apparent response to the desire for something more immediately utilitarian, the technical working group of the consortium announced that it would "focus its attention" on two of those components: the AdsML Business Processes and the AdsML Envelope. "When we started doing real work, membership started going up," Stewart said. "The closer we get to the real thing, the more excitement there is."
In addition, membership has increased from the 37 members it listed in its 1.0 Framework Overview to the recent roster of 46 members, including international trade organizations, newspaper companies, consultants and suppliers, a wire service, and an assortment of other organizations and suppliers from around the globe. In some key ways, this growth represents the globalization of what had been the mostly U.S.-centric relationships between American newspapers and suppliers and vice versa. These new documents show signs of greater flexibility in creating a standard in the face of already mature business processes.

  For example, the third document, AdsML Requirements, dated Dec. 22, 2004, says that the working group "decided to relax the requirement that items conveyed within an AdsML envelope must themselves be valid XML documents." Instead, "most textual formats (including but not limited to well-formed XML documents, tab- and comma-delimited files, and non-compiled EDI messages)" can be conveyed in the AdsML envelope, along with material formatted in existing standards, such as CREST, SpaceML and AdConnexion.

  Elsewhere, the requirements document states that AdsML "shall not force an implementer to follow a particular processing model," that AdsML "should support both synchronous and asynchronous transactions," (although it seems to prefer the asynchronous mode because it minimizes locking system resources and bookings, enabling systems to continue operating after a message has been sent) and that it "shall be independent of transfer protocols."

  The working group also waived the previous requirement that the envelope contain enough information to allow the recipient to verify the formats of the advertising content contained in or referenced by the envelope. Instead of being part of the design of the envelope, this requirement will be included in the analysis of XML standards and vocabularies. And in the hopes of speeding up processing a bit, AdsML implementation no longer requires sending a response message once system testing indicates that things are working smoothly.

  In its Overview, Phase II is now described as consisting of two mutually supportive (but also autonomous) standards for the exchange of advertising information: the AdsML Bookings specification, which was initially a "sub-project"; and the AdsML Structured Descriptions of Advertisement Objects, a "proposed specification" document for describing the contents of an advertisement that went public in September 2004.

  While the overview describes two standards, it also describes three business goals in response to membership requests: ad bookings, classified ads distribution and ad content delivery. And it still maintains a goal of eliminating "the marketplace confusion caused by having to choose from too many overlapping standards" by establishing "direct and indirect liaisons with the owners of those standards," as well as beginning work with the CIP4 Advertising Workgroup to design an interface between AdsML and JDF.

  Other issues addressed in the proposed Phase II specification include interchange format and non-technical aspects, model vocabularies (for housing, recruitment, transportation, travel, miscellaneous products and services) based on the CREST 2.0 standard, transmission options, and ad content delivery standards (only partially completed) for transmitting formatted or unformatted advertisement content.
The proposed specification for the AdsML E-Commerce Overview, also begun around August 2004, reiterates the importance of the AdsML envelope and the item-level standards for defining the "XMLmessage formats for specific types of information or transactions" that fit into the envelope.

  Again, unlike the earlier released documents, we see an increased interest in highlighting the flexibility of the standard. For example, "use of the AdsML Envelope, while encouraged, is optional, and the Item-Level standards can be used both inside and outside of the AdsML envelope." Elsewhere, it notes that "while the message structure of each standard is tightly fixed, flexibility has been provided to allow regional groups to extend or replace many of the AdsML controlled vocabularies."
The document describes how to achieve interoperability in business processes and terminology, regional customization of standards and trading partner agreements. It emphasizes the importance of message choreography - that the systems at each end of the message transfer "have the same view on which messages to send and which to expect to receive." (But it also renders optional the "preferred messaging model" of request-response.)

  These messages are broken into four types: business transaction, material delivery, broadcast and administrative. Each message also has a unique code identifying, for example, whether it's an ad order, an ad order change or a cancellation. And while the overall view of the consortium is that manual intervention anywhere in the advertising life cycle increases the possibility for error, this specification allows for the integration, with constraints, of manual messages into the "AdsML choreography."
This is done with the understanding that "given the state of existing systems, in most environments AdsML will initially be used for just some of the defined messages, leaving the rest of the business interactions to be accomplished by 'manual' processes such as phone, fax or e-mail."

  Those who implement AdsML are also advised that they are responsible for suitably protecting and/or encrypting messages traveling between sender and receiver - something that is normally accomplished at a "higher level" than the AdsML business message.

  Interestingly, the requirements document begins to refer to something called "the AdsML community." Not members, not users. A community. But more importantly, this document begins to describe some 53 information content requirements, including the ability to handle details related to advertisers, booking, accounts and the classification and categorization of advertisement content, as well as all sorts of variables that can occur in the life cycle of an advertisement. It also reiterates the list of 36 business processes that describe, for example, whether the item is an order for an advertisement, an invoice, a query or a complaint. Most important of all, perhaps, it includes four pages that describe what is required for AdsML conformance operationally, structurally and syntactically, and covers issues such as allowable item content, communication with internal system, creation of AdsML messages, message logging and validation. (This was explained in considerably more detail in an earlier document, "AdsML Processing Model, Addressing and Operational Conformance.")
The Phase II Overview status declares that "the completion of a 'standalone' message format for the delivery of ad content that arrives separately from a booking" has been postponed until a later phase of work. The first draft of "Bookings" was approved in July. "Ad Content Delivery" has a planned release of October, which is well before the e-invoices that Stewart projects for release next year.