OpenEFT (Enhanced for Tablet)
Interactive Ad Delivery Guide

Version 1.0

 

 

September 30, 2013

 

 

 

 

 

 

 

Description: idealliancelogo_cymk


Copyright and Legal Notices

© 2001 – 2013 International Digital Enterprise Alliance, Inc.  All Rights Reserved.

PRISM® and nextPub® are registered trademarks of the International Digital Enterprise Alliance, Inc. (IDEAlliance).

This document may be downloaded and copied provided that the above copyright notice and this Notice are included on all such copies.  This document itself may not be modified in any way, except as needed for the purpose of developing International Digital Enterprise Alliance, Inc. (“IDEAlliance”) specifications.  Use of the specification or standard set forth in this document shall not create for the user any rights in or to such specification or standard or this document, which rights are exclusively reserved to IDEAlliance or its licensors or contributors.

Use of this document and any specification or standard contained herein is voluntary.  By making use of this document or any specification or standard contained herein, the user assumes all risks and waives all claims against IDEAlliance, its licensors and contributors.  By making this document available, IDEAlliance is not providing any professional services or advice to any person or entity.  Any person or entity utilizing this document or any specification or standard contained herein should rely upon the advice of a competent professional before using any such information. 

NO WARRANTY, EXPRESSED OR IMPLIED, IS MADE REGARDING THE ACCURACY, ADEQUACY, COMPLETENESS, LEGALITY, RELIABILITY OR USEFULNESS OF ANY INFORMATION CONTAINED IN THIS DOCUMENT OR IN ANY SPECIFICATION OR STANDARD OR OTHER PRODUCT MADE AVAILABLE BY IDEALLIANCE. THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN AND INCLUDED IN ANY SPECIFICATION OR STANDARD OR OTHER PRODUCT OR SERVICE OF IDEALLIANCE IS PROVIDED ON AN "AS IS" BASIS. IDEALLIANCE DISCLAIMS ALL WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, ANY ACTUAL OR ASSERTED WARRANTY OF NON-INFRINGEMENT OF PROPRIETARY RIGHTS, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.

IN NO EVENT SHALL IDEALLIANCE, ITS LICENSEES, CONTRIBUTORS OR THEIR RESPECTIVE OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, REPRESENTATIVES, SUPPLIERS OR CONTENT OR SERVICE PROVIDERS BE LIABLE FOR DAMAGES OF ANY KIND, INCLUDING WITHOUT LIMITATION, DIRECT, INDIRECT, COMPENSATORY, SPECIAL, INCIDENTAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION DAMAGES FROM DATA LOSS OR BUSINESS INTERRUPTION) EVEN IF MADE AWARE OF THE POSSIBILITY OF SUCH DAMAGES, WHETHER IN AN ACTION UNDER CONTRACT, TORT OR ANY OTHER THEORY, ARISING OUT OF OR IN CONNECTION WITH THE USE, INABILITY TO USE OR PERFORMANCE OF THIS DOCUMENT, THE SPECIFICATION OR STANDARD CONTAINED HEREIN, OR ANY OTHER DOCUMENT OR SPECIFICATION OR STANDARD MADE AVAILABLE BY IDEALLIANCE. 

Some states do not allow the disclaimer or limitation of damages, so the disclaimers set forth above apply to the maximum extent permitted under applicable law.

IDEAlliance takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed or implicated with respect to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available.  IDEAlliance does not represent that it has made any effort to identify any such rights. Information on IDEAlliance's procedures with respect to rights in IDEAlliance specifications can be found at the IDEAlliance website at www.idealliance.org.  Copies of third-party claims of rights, assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the President of IDEAlliance at patent-disclosure@idealliance.org.

IDEAlliance requests interested parties to disclose any copyrights, trademarks, service marks, patents, patent applications, or other proprietary or intellectual property rights which may cover technology that may be required to implement this specification. Please address the information to the President of IDEAlliance at patent-disclosure@idealliance.org.


Table of Contents

1     Status. 1

1.1        Document Status. 1

1.2        Document Location. 1

1.3        Version History. 1

2     Introduction. 3

2.1        The Challenge. 3

2.2        What is EFT?. 3

2.3        What is an Open Format?. 4

2.4        The Scope. 4

2.5        Designing OpenEFT. 4

2.6        Relationship to Other Specifications. 5

2.6.1         Extensible Markup Language (XML) 5

2.6.2         Publishing Requirements for Industry Standard Metadata (PRISM) 5

2.6.3         Dublin Core (DC) 5

2.6.4         GWG/IDEAlliance Ad Ticket, AdsML and ADAM. 5

2.6.5         Ad-ID.. 6

2.6.6         SAINT (Standard Advertising Insertion Nomenclature for Tablets) 6

2.6.7         IDPF (International Digital Publishing Forum) EPUB 3.0. 6

2.6.8         HTML5. 6

2.7        Version 1.0 Use Cases. 6

2.8        Diagrams. 7

2.9        Documentation Conventions. 8

2.10      The OpenEFT Model 8

2.11      The OpenEFT Zip Format 9

2.12      The OpenEFT Ad Delivery Model 9

3     Ad Contents of the Issue XML File. 11

3.1        Device Specifications. 11

3.2        Ad Delivery. 12

3.3        Linking Mechanisms. 12

4     OpenEFT Ad Format 13

4.1        Item and Page References. 13

4.2        The Ad Metadata Block. 13

4.3        About the Ad Layout 14

4.4        Enhancements. 15

4.4.1         Specifying the Type of Enhancement 16

4.4.2         Placement of Enhancements in an Ad. 16

4.4.3         Linking to the Enhancement 16

4.5        About HTML5 Ads. 17

4.6        A Special Note. 19


1      Status

1.1     Document Status

This document represents the IDEAlliance OpenEFT Interactie Ad Delivery Guide [IADGUIDE] V1.0.

ü

Draft for Public Comment

August 5, 2013

ü

Draft for Public Comment

August 31, 2013

ü

Version 1.0 Release

September 30, 2013

1.2     Document Location

Links to this document (OpenEFT Ad Delivery Guide [OEADGUIDE] can be found at www.openeft.org.

1.3     Version History

Version Number

Release Date

Editor

Description

1.0 Public Draft

08/05/2013

Kennedy

Public Draft for Comment

1.0 Public Draft

08/31/2013

Kennedy

Public Draft for Comment

1.0 Release

09/30/2013

Kennedy

Released Specification


2      Introduction

2.1     The Challenge

In the three years since the iPad hit the market, those who publish highly-designed, interactive content on tablets and mobile devices are still finding the production of each digital edition a “one-off” proposition. Economies of scale remain elusive, and production costs remain exceptionally high.  All across the industry, in our meetings with CTOs of major magazines, production staff in the trenches, and developers of digital newsstands, it is clear that the industry blames the lack of innovation and lack of emerging competitive, new production tools on the absence of an open standard for the packaging, delivery and display of magazine content on tablets.  With only proprietary formats available, this is not likely to change in the near-term.  While a great deal of thought and attention has been given to long-term, strategic solutions, what’s lacking for the near term is the cost-saving tactical solution that an open format would offer.  Without disruption to existing workflows, publishers want the ability to produce and export their content, including all associated interactive elements, into one standardized format for display across a wide range of devices.

As a global association with a focus on technologies that power the digital media supply chain, IDEAlliance has a strong history of fostering the development of open specifications through its work with W3C, IDPF, ANSI, ISO as well as through our own working groups.  Our extensive experience indicates that published technical specifications reduce variability and increase automation/efficiency across workflows and throughout the media supply chain.  By publishing an open format for the delivery and rendition of magazines on tablets, IDEAlliance fulfills its mission to enhance the media value chain through standardization and foster technology innovation to remove friction and improve industry profitability.

2.2     What is EFT?

EFT or “Enhanced for Tablets” is a term developed by the Tablet Task Force of the Magazine Media Association (MPA) and adopted by other industry groups across the magazine media supply chain.  EFT is one of the four terms to describe tablet magazine publications.  See http://www.magazine.org/insights-resources/guidelines/tablet-metrics.

SFP (Straight From Print) editorial or advertising content where the page on the screen looks exactly like the print page — with no interactive enhancements (except for the activation of links)

SFP+ editorial or advertising content where the page on the screen looks exactly like the print page — with some interactive enhancements (beyond activation of links)

DFT (Designed For Tablet) editorial or advertising content where the page on the screen has been re-designed specifically for reading on the tablet and is meant to be displayed at 100% (that is, there is no need to tap and zoom) 

EFT (Enhanced For Tablet) adding enhancements and bonus content to Designed For Tablet (DFT) editorial or advertising content to more fully utilize the tablet medium (e.g., hotspots, photographic slide shows, video, audio, in-app browser)

Since EFT is recognized across the industry as the term for today’s enhanced magazine publishing format on tablets, IDEAlliance has named the new open format the OpenEFT format.

2.3     What is an Open Format?

In the context of this initiative, an Open Format is a published, standardized format for the packaging, delivery and display content across a wide range of tablets of different sizes, aspect ratios, resolutions and operating systems.  An open format is a specification that has been approved by the industry, is freely available to supply chain partners – both customers and technology providers, and is managed and enhanced over time through an open process by a specification-development body, such as IDEAlliance.

OpenEFT (www.openeft.org) is the first open format for the packaging, delivery and rendition of magazine and other highly-designed content to tablets and mobile devices.

2.4     The Scope

The scope of the Version 1.0 effort is limited to any design-based publication that is based on pre-rendered pages presented as PDFs, page images, HTML5 or XHTML.  Magazines will clearly be the primary beneficiaries of the publication of an OpenEFT.  But any other highly-designed publication stands to benefit as well.  This includes highly-designed display books (such as cookbooks and “coffee table” books), design-dependent textbooks and bookazines (books with advertisements).   An industry-wide effort was required to assure that the needs of both publishers and digital newsstands are met.

2.5     Designing OpenEFT

The design of OpenEFT was based on the following principles:

1.      OpenEFT must be based on open industry standards.  These include specifications from W3C, ISO, Dublin Core, IDPF, Ad-ID, AdsML and GWG.

2.     OpenEFT must be based on IDEAlliance Specifications.  These include PRISM, SAINT, ADAM, EVE and the Joint IDEAlliance/GWG Ad Ticket.

3.     Adopting OpenEFT must not cause major disruption to existing tablet publishing workflows.

4.     Implementing OpenEFT must be as simple and straightforward as possible because OpenEFT must provide a tactical solution for the industry.

5.     OpenEFT must support the delivery of all four types of tablet magazine editions as defined by the Association of Magazine Media.

6.     OpenEFT must support enhancement types that are common across 2013 tablet editions.

7.     OpenEFT must enable dynamic sizing and placement of enhancement layers for tablets of different dimensions but with a common aspect ratio.

8.     OpenEFT must provide a fall-back mechanism for the delivery and rendering of rich media due to differences in format rendering capabilities imposed by different tablet operating systems.

9.     OpenEFT must consider the advertising workflow and the integration of advertising into tablet magazine editions.

10.  OpenEFT should be designed so that highly-designed publications, other than magazines, can adopt this format.

11.    OpenEFT must consider today’s requirements as defined by our members who are magazine publishers, digital newsstands and all stakeholders in the digital media supply chain – both in the United States and Internationally.

12.  OpenEFT must design for the future by embracing emerging technologies, including HTML5.

13.   OpenEFT must design for the future by providing a flexible model that will enable publishers and advertisers to develop new kinds of enhancements over time.

14.  OpenEFT must support today’s tablet publishing models (2.2) while providing a bridge to the future that will enable magazine publishers to embrace new rendering and layout technologies currently under development by IDPF.

2.6     Relationship to Other Specifications

IDEAlliance has a history of building its specifications on existing open standards and specifications whenever possible.  This section discusses the standards leveraged to develop the OpenEFT Format.

2.6.1   Extensible Markup Language (XML)

OpenEFT is an application of XML [W3C-XML]. The packaging and delivery structures are represented using XML. XSDs are provided for each.  Because OpenEFT uses elements from many existing schemas, it makes use of XML concepts such as Namespaces[W3C-XML-NS].

2.6.2   Publishing Requirements for Industry Standard Metadata (PRISM)

OpenEFT leverages PRISM metadata whenever possible.  PRISM is an IDEAlliance Specification that defines a set of metadata vocabularies to facilitate management, aggregating, packaging, styling and delivery of content across publishing channels and platforms.  PRISM provides a framework for the interchange and preservation of content and metadata, a collection of elements to describe that content, and a set of controlled vocabularies listing the values for those elements.  Metadata elements from the PRISM Basic Metadata Specification [PRISMBMS] and the PRISM Advertising Metadata Specification [PRISMADMS] are employed in the OpenEFT Specification.  In addition controlled vocabularies from the PRISM Controlled Vocabularies Specification [PRISMCVS] are used.

2.6.3   Dublin Core (DC)

The Dublin Core Metadata Initiative [DCMI] established a set of metadata to describe electronic resources in a manner similar to a library card catalog. The Dublin Core includes 15 general elements designed to characterize resources. PRISM, and hence OpenEFT uses the Dublin Core and its relation types as the foundation for its metadata.

2.6.4   GWG/IDEAlliance Ad Ticket, AdsML and ADAM.

Wherever possible the metadata fields defined for advertising are based on the Joint Ghent Work Group (GWG)/IDEAlliance Ad ticket V2.0 metadata fields, which in turn are based on fields defined for the industry by AdsML.  Additional fields developed by IDEAlliance and included in the PRISM Advertising Metadata Specification [PRISMADMS] and the Asset Delivery Advertising Metadata Specification [ADAM] are also employed.

2.6.5   Ad-ID

Ad-ID is a consortium of the 4A’s (American Advertising Association) and the ANA (Association of National Advertisers).  Ad-ID provides a unique identifier and associated metadata for each advertisement, across all media types.  Ad-ID is cited as one mechanism for providing a unique identifier for each advertisement in the OpenEFT package.

2.6.6   SAINT (Standard Advertising Insertion Nomenclature for Tablets)

The SAINT Specification [SAINT] provides a standard lexicon that will be used in the specification for all tablet publishing advertising.  Terms from SAINT are used extensively throughout the OpenEFT model as element and attribute names. SAINT was developed by the IDEAlliance Digital Ad Lab Working Group.  See www.digital-ad-lab.org for more information.

2.6.7   IDPF (International Digital Publishing Forum) EPUB 3.0

EPUB is an accessible, portable document format based on HTML5, XML and other Web Standards that is widely adopted for digital books and other publications for eReaders, tablets, smartphones, and PCs. The long-term goal of IDPF is that the newest version of EPUB, EPUB 3.0 [EPUB3], would be utilized for a broad range of content, including books, magazines and educational, professional and scientific publications.  To that end, IDPF has a roadmap to develop new layout models that can support dynamically rendered magazine content as well as book content.  In the short term, OpenEFT will make use of the EPUB Open Packaging Format (OPF) to package magazine content.  In the long term, OpenEFT can serve as a bridge to eventual adoption and use of IDPF advanced layout models as they are developed and reach maturity.  The leadership of IDEAlliance and IDPF has collaborated throughout the development of OpenEFT with the intent of specifying OpenEFT as a profile of EPUB 3.0 for magazines.

2.6.8   HTML5

HTML5 [HTML5] is a markup language and core technology of the Web.  Its immediate predecessors are HTML 4.01 and XHTML 1.1.  HTML5 brings together and advances these specifications and serves as the basis for both the IDPF EPUB 3.0 [EPUB3] effort and the IDEAlliance PRISM Source Vocabulary.  HTML5 was developed to work seamlessly with Cascading Style Sheets [CSS] and Javascript.  Development has been a joint effort of the World Wide Web Consortium, W3C, and the Web Hypertext Application Technology Working Group (WHATWG).  OpenEFT was written to accommodate HTML5 encoding of magazine and advertising content.  It also uses HTML5 attribute and microsyntax conventions in the OpenEFT Format.

2.7     Version 1.0 Use Cases

OpenEFT Version 1.0 was built to support three specific use cases:

·        Use Case #1: Exchange and rendering of magazine issues that are made up of pre-rendered pages that were designed with a layout for print and repurposed for tablets and mobile devices.  This use case is often called the “replica” magazine model.

·        Use Case #2: Exchange and rendering of magazine issues that are made up of pre-rendered pages that were designed with a layout for specifically for tablets and mobile devices. This use case is often called the “digital” magazine model.

·        Use Case #3: Exchange of digital advertising that was specifically designed with a layout for tablets and mobile devices and that often contain interactive enhancements. This use case is often called the “advertising delivery” model.

2.8     Diagrams

In this Specification, the OpenEFT XML model is illustrated using model diagrams produced with the oXygen XML product.  These diagrams show the element and attribute structures. 

The legend for reading XML model diagrams is shown in Figure 2.2.  Elements that are required by the model are shown in a solid box.  Elements that are optional are shown in a transparent box.  Likewise, attributes may be required (solid box) or optional (transparent box).  A repeatable occurrence of elements is indicated by numbers below each element box to the right. 

The diagrams also indicate how elements are assembled. When building some models, elements may occur in a sequence with a specified order.  Other models provide a choice from among a number of elements.  The legend in Figure 2.1 shows the connectors for sequence and choice.

Figure 2.1 Legend for XML Diagrams

2.9     Documentation Conventions

When an XML element is discussed in documentation, it is expressed with a leading angle bracket (<) to indicate that the topic is an element from either the package schema or the formatting schema.  When attributes are discussed in documentation, the attribute name is expressed with a trailing equals sign (=) to indicate that the topic is about an attribute.

2.10  The OpenEFT Model

For OpenEFT the root file is always the *.OPF file.  The OpenEFT OPF file is based on the EPUB 3.0 Publications Document.  The OPF is an XML file that, for OpenEFT, consists of a <metadata element that uses PRISM/Dublin Core metadata to identify the magazine issue, has a <manifest element that lists all components found in the package (so the receiver can verify that the package is complete and ready to render in its entirety), and a <spine element that, in the case of OpenEFT, points to the XML file for the issue or the publication.  See Figure 2.2.

Figure 2.2 Simplified View of the OpenEFT Model

2.11  The OpenEFT Zip Format

OpenEFT V1.0 employs a simplified version the EPUB packaging model.   See Figure 2.3 for one possible OpenEFT package organization.  The packaging format is documented in the OpenEFT Packaging Specification [OEFTPS}.

Note: Other than the requirement that the container.xml file must be placed in the META-INF folder, OpenEFT writing software can organize files within the .zip file any way they choose.

Figure 2.3 Example of One Possible OpenEFT .zip file Structure

For further documentation on packaging reference, see the OpenEFT Packaging Specification V1.0 [OEFTPS].

2.12  The OpenEFT Ad Delivery Model

When the OpenEFT package is used to deliver an ad within a magazine issue, the ad is packaged within the <issue.xml file.  The content of the package is specified as <adDelivery.  The Ad Delivery model shown in this Guide can be used to deliver one or more ads between a materials provider and the publisher that will insert the ad into the digital edition.  See Figure 2.4.

Figure 2.4 OpenEFT Ad Model

 


3      Ad Contents of the Issue XML File

The OPF file points processors to the issue XML file.  This provides further information about the issue of the magazine where the ad is being placed and a link(s) to the digital ad files being delivered.  See Figure 3.1.

Figure 3.1 The Issue XML File

3.1     Device Specifications

An important metadata block for each issue is the description of the device the issue was prepared for.  Issues may either be prepared to absolute measurements or relative ones.  When using absolute measurements, the layout will differ for a 10 inch and a 7 inch tablet. 

The device information for an issue may be specified using relative measurements.  These measurements are percentages based on a specified aspect ratio.  This means the publisher may prepare one layout and it can size for any device that has the specified aspect ratio (within a range of acceptability).  That means a single layout may work for both a 7 inch and 10 inch tablet if they both have a 4:3 aspect ratio.

Note: For a magazine designed for tablets, the same underlying ad rendition may be used for any device of the same aspect ratio. If this is the intention, when adding interactive enhancements to an ad, best practice is to use relative placement so that when the ad is scaled for different tablet sizes, the placement of any enhancement will work.

3.2     Ad Delivery

Instead of including content and ads directly in the issue.xml file, links to content and ads are provided.  This makes the model highly flexible.  In the case of using OpenEFT to transmit ads, a series of ad links is used.  See Figure 3.2.

Note:  The href= attribute on the ad link connects us to each ad in the package.  It uses the W3C spatial clipping syntax where the URI link is pathname/filename#id=.  In other words, the value for the href= matches the ID in the indicated file in the OpenEFT package

Figure 3.2 Ad Links in OpenEFT

3.3     Linking Mechanisms

The mechanism to link the declaration for each content item, advertisement or page in the issue is through the href= attribute on the <itemLink, <adLink or <pageLink which has a URI value.  The form of the value for the href= attribute is "path/filename#id=xx".  The value given for the href= attribute in each link element matches it with the target component definition with the matching ***ID= attribute.  See Figure 3.3.

Figure 3.3 href= Link Mechanism

.


4      OpenEFT Ad Format

The ad delivery block of the issue is made up of a number of ad links.  The linking is accomplished using the standard W3C href= mechanism.  See Figure 4.1.

Figure 4.1 Ad Linking

4.1     Item and Page References

The <itemRef and <pageRef elements are optional and provide a way to indicate a relationship between this ad and an item of content and /or a page.  These are not XML links and are informational only.  These tags provide an aid for ad insertion by the Publisher.  See Figure 4.1.

4.2     The Ad Metadata Block

Each Ad in OpenEFT is s required to have a unique identifier.  The ad is made up of metadata about that ad and the ad layout.  One or more sets of ad layouts are permitted based on orientation.  The ad metadata is metadata that describes the digital ad.  This metadata block is based on the joint IDEAlliance/GWG Ad Ticket and includes information such as the creative that produced the ad, the advertiser, the brand, the product, etc.  This metadata is passed from the Creative to the Publisher during the process of ad exchange and can be used to verify ad insertion according to the booking.  See Figure 4.2 for the ad metadata model.

Note: Two new fields, prism-ad:expirationDate and prism-ad:priority have been added to enable the placement of multiple digital ads in a single ad reservation space over the life of the digital edition.

Figure 4.2 Ad Metadata

4.3     About the Ad Layout

The ad layout provides a definition for the size and layout of the ad, including interactive enhancements and an optional text version of the ad copy.  The ad layout is placed on the page as part of the definition of a page of the issue.  See Figure 4.3 for a model of ad layout.

Figure 4.3 Ad Layout Model

Note:  The placement of the ad layout on a page is declared within the definition for the layout of the page on which the ad is being placed and not within the ad itself.

4.4     Enhancements

An unbounded number of enhancements may be placed over any page rendition.  Enhancements will be rendered in the order they are placed on a page.  The tagging for enhancements provides the placement of the enhancement and a link to the enhancement within the OpenEFT package.  See Figure 4.4

Figure 4.4 Enhancement Model

Note: Some enhancement models allow for other enhancements to be placed within them.  In this case, (such as for scrollable frame) the coordinates for placement are to be within the parent frame.  Some types of enhancements do not allow other enhancements to be placed within them.  An example is a video.

4.4.1   Specifying the Type of Enhancement

An optional type= attribute is provided to document the type of enhancement being placed.  The purpose of this attribute is informational only.  The href= attribute makes the actual call to include the enhancement at the point of placement.

4.4.2   Placement of Enhancements in an Ad

The ad layout model allows for the placement of enhancements in an ad.  This is accomplished by providing coordinates for placement and area using the xywh= attribute.    The placement declaration may be either absolute or relative.  Coordinates are specified with W3C spatial clipping syntax.  A prefix of pixel: indicates the coordinates are specified as absolute pixels.  A prefix of percent: indicates the coordinates are specified as percent of parent frame.

Note: While the model allows for one enhancement to be placed using absolute measure and a following enhancement to be placed using relative measures, best practice is to select a placement method and use that throughout the issue.

4.4.3   Linking to the Enhancement

The link to the definition of the enhancement uses the standard href= mechanism.  See Figure 4.5.

Figure 4.5 Linking Enhancements to a Page

4.5     About HTML5 Ad Enhancements

Today, digital agencies specialize in the production of HTML5 ads.  This sort of ad should be specified as a type “custom”.  Here the specification of Operating System and Version in the <deviceInfo tag is advised.  The custom ad has fields to communicate the script types, path, class and parameters that will be required to render the ad accurately.  All components of an HTML5 ad, including the scripts, are packaged and exchanged using the OpenEFT packaging schema.  See Figure 4.6.

Diagram

Figure 4.6 Custom Enhancement for delivering HTML5 Ads

4.6     About HTML5 Ad Renditions

Today, some ads may be delivered completely in HTML5.  In this case the underlying “page rendition” is not a PDF or a bitmap image but HTML code.  OpenEFT provides for this condition.  If the underlying rendition is HTML or HTML5, simply use the href= attribute to point to that underlying HTML page:

<ad id=“ad000067”>

<adMetadata>. . .</adMetadata>

<adLayout orientation=“portrait”>

  <ad Area wh=“percent:100,100”/>

  <enhancement xywh=“percent:50,0, 100,25” href= “e000067.xml” type=”video”/>

--includes e000067,xml:
          <video id=“v000067”>

              <source src=“v000067.ogg”/>

             <source src=“v000067.webm”/>

           </video>

  <rendition href=“ad000067.htm”/><!-- calls HTML ad rendition -->

</adLayout>

</ad>

4.7     A Special Note

This ad model has been designed to enable not only the production, interchange and rendering of full page ads, but fractional ads as well.  Ads have been given an expiration date so they may have only a finite run-time in the online life of a digital publication.  Further, this model allows for more than one ad to be sold into a single ad space.  Publishers may rotate what a reader sees each time they revisit a popular page or story within the digital edition.