Format type comments - one sentence per line

This commit is contained in:
Max Cherry
2017-10-01 12:29:59 +03:00
parent f292c3e2a9
commit e2f85b80f8
25 changed files with 123 additions and 152 deletions
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.14 Object: App
//
// This object should be included if the ad supported content is a non-browser application (typically in
// mobile) as opposed to a website. A bid request must not contain both an App and a Site object. At a
// minimum, it is useful to provide an App ID or bundle, but this is not strictly required.
// This object should be included if the ad supported content is a non-browser application (typically in mobile) as opposed to a website.
// A bid request must not contain both an App and a Site object.
// At a minimum, it is useful to provide an App ID or bundle, but this is not strictly required.
type App struct {
// Attribute:
+7 -9
View File
@@ -2,16 +2,14 @@ package openrtb
// 3.2.8 Object: Audio
//
// This object represents an audio type impression. Many of the fields are non-essential for minimally
// viable transactions, but are included to offer fine control when needed. Audio in OpenRTB generally
// assumes compliance with the DAAST standard. As such, the notion of companion ads is supported by
// optionally including an array of Banner objects (refer to the Banner object in Section 3.2.6) that define
// these companion ads.
// This object represents an audio type impression.
// Many of the fields are non-essential for minimally viable transactions, but are included to offer fine control when needed.
// Audio in OpenRTB generally assumes compliance with the DAAST standard.
// As such, the notion of companion ads is supported by optionally including an array of Banner objects (refer to the Banner object in Section 3.2.6) that define these companion ads.
//
// The presence of a Audio as a subordinate of the Imp object indicates that this impression is offered as
// an audio type impression. At the publishers discretion, that same impression may also be offered as
// banner, video, and/or native by also including as Imp subordinates objects of those types. However, any
// given bid for the impression must conform to one of the offered types.
// The presence of a Audio as a subordinate of the Imp object indicates that this impression is offered as an audio type impression.
// At the publishers discretion, that same impression may also be offered as banner, video, and/or native by also including as Imp subordinates objects of those types.
// However, any given bid for the impression must conform to one of the offered types.
type Audio struct {
// Attribute:
+6 -9
View File
@@ -2,16 +2,13 @@ package openrtb
// 3.2.6 Object: Banner
//
// This object represents the most general type of impression. Although the term “banner” may have very
// specific meaning in other contexts, here it can be many things including a simple static image, an
// expandable ad unit, or even in-banner video (refer to the Video object in Section 3.2.7 for the more
// generalized and full featured video ad units). An array of Banner objects can also appear within the
// Video to describe optional companion ads defined in the VAST specification.
// This object represents the most general type of impression.
// Although the term “banner” may have very specific meaning in other contexts, here it can be many things including a simple static image, an expandable ad unit, or even in-banner video (refer to the Video object in Section 3.2.7 for the more generalized and full featured video ad units).
// An array of Banner objects can also appear within the Video to describe optional companion ads defined in the VAST specification.
//
// The presence of a Banner as a subordinate of the Imp object indicates that this impression is offered as
// a banner type impression. At the publishers discretion, that same impression may also be offered as
// video, audio, and/or native by also including as Imp subordinates objects of those types. However, any
// given bid for the impression must conform to one of the offered types.
// The presence of a Banner as a subordinate of the Imp object indicates that this impression is offered as a banner type impression.
// At the publishers discretion, that same impression may also be offered as video, audio, and/or native by also including as Imp subordinates objects of those types.
// However, any given bid for the impression must conform to one of the offered types.
type Banner struct {
// Attribute:
+16 -23
View File
@@ -2,34 +2,27 @@ package openrtb
// 4.2.3 Object: Bid
//
// A SeatBid object contains one or more Bid objects, each of which relates to a specific impression in the
// bid request via the impid attribute and constitutes an offer to buy that impression for a given price.
// A SeatBid object contains one or more Bid objects, each of which relates to a specific impression in the bid request via the impid attribute and constitutes an offer to buy that impression for a given price.
//
// For each bid, the nurl attribute contains the win notice URL. If the bidder wins the impression, the
// exchange calls this notice URL to inform the bidder of the win and to convey certain information using
// substitution macros (see Section 4.4) such as the clearing price. The win notice return or the adm
// attribute can be used to serve markup (see Section 4.3). In either case, the exchange will also apply the
// aforementioned substitution to any macros found in the markup.
// For each bid, the nurl attribute contains the win notice URL.
// If the bidder wins the impression, the exchange calls this notice URL to inform the bidder of the win and to convey certain information using substitution macros (see Section 4.4) such as the clearing price.
// The win notice return or the adm attribute can be used to serve markup (see Section 4.3).
// In either case, the exchange will also apply the aforementioned substitution to any macros found in the markup.
//
// BEST PRACTICE: The essential function of the win notice is to inform a bidder that they won an auction. It
// does not necessarily imply ad delivery, creative viewability, or billability. Exchanges are highly
// encouraged to publish to their bidders their event triggers, billing policies, and any other meaning they
// attach to the win notice. Also, please refer to Section 7.2 for additional guidance on expirations.
// BEST PRACTICE: The essential function of the win notice is to inform a bidder that they won an auction.
// It does not necessarily imply ad delivery, creative viewability, or billability.
// Exchanges are highly encouraged to publish to their bidders their event triggers, billing policies, and any other meaning they attach to the win notice.
// Also, please refer to Section 7.2 for additional guidance on expirations.
//
// BEST PRACTICE: Firing of the billing notice should be server-side and as “close” as possible to where the
// exchange books revenue in order to minimize discrepancies between exchange and bidder.
// BEST PRACTICE: Firing of the billing notice should be server-side and as “close” as possible to where the exchange books revenue in order to minimize discrepancies between exchange and bidder.
//
// BEST PRACTICE: For VAST Video, the IAB prescribes that the VAST impression event is the official signal
// that the impression is billable. If the burl attribute is specified, it too should be fired at the same time if
// the exchange is adhering to this policy. However, subtle technical issues may lead to additional
// discrepancies and bidders are cautioned to avoid this scenario.
// BEST PRACTICE: For VAST Video, the IAB prescribes that the VAST impression event is the official signal that the impression is billable.
// If the burl attribute is specified, it too should be fired at the same time if the exchange is adhering to this policy.
// However, subtle technical issues may lead to additional discrepancies and bidders are cautioned to avoid this scenario.
//
// Several other attributes are used for ad quality checks or enforcing publisher restrictions. These include
// the advertiser domain via adomain, a non-cache-busted URL to an image representative of the content
// of the campaign via iurl, an ID of the campaign and of the creative within the campaign via cid and
// crid respectively, an array of creative attribute via attr, and the dimensions via h and w. If the bid
// pertains to a private marketplace deal, the dealid attribute is used to reference that agreement from
// the bid request.
// Several other attributes are used for ad quality checks or enforcing publisher restrictions.
// These include the advertiser domain via adomain, a non-cache-busted URL to an image representative of the content of the campaign via iurl, an ID of the campaign and of the creative within the campaign via cid and crid respectively, an array of creative attribute via attr, and the dimensions via h and w.
// If the bid pertains to a private marketplace deal, the dealid attribute is used to reference that agreement from the bid request.
type Bid struct {
// Attribute:
+6 -7
View File
@@ -2,14 +2,13 @@ package openrtb
// 3.2.1 Object: BidRequest
//
// The top-level bid request object contains a globally unique bid request or auction ID. This id attribute is
// required as is at least one impression object (Section 3.2.4). Other attributes in this top-level object
// establish rules and restrictions that apply to all impressions being offered.
// The top-level bid request object contains a globally unique bid request or auction ID.
// This id attribute is required as is at least one impression object (Section 3.2.4).
// Other attributes in this top-level object establish rules and restrictions that apply to all impressions being offered.
//
// There are also several subordinate objects that provide detailed data to potential buyers. Among these
// are the Site and App objects, which describe the type of published media in which the impression(s)
// appear. These objects are highly recommended, but only one applies to a given bid request depending
// on whether the media is browser-based web content or a non-browser application, respectively.
// There are also several subordinate objects that provide detailed data to potential buyers.
// Among these are the Site and App objects, which describe the type of published media in which the impression(s) appear.
// These objects are highly recommended, but only one applies to a given bid request depending on whether the media is browser-based web content or a non-browser application, respectively.
type BidRequest struct {
// Attribute:
+8 -8
View File
@@ -2,15 +2,15 @@ package openrtb
// 4.2.1 Object: BidResponse
//
// This object is the top-level bid response object (i.e., the unnamed outer JSON object). The id attribute
// is a reflection of the bid request ID for logging purposes. Similarly, bidid is an optional response
// tracking ID for bidders. If specified, it can be included in the subsequent win notice call if the bidder
// wins. At least one seatbid object is required, which contains at least one bid for an impression. Other
// attributes are optional.
// This object is the top-level bid response object (i.e., the unnamed outer JSON object).
// The id attribute is a reflection of the bid request ID for logging purposes.
// Similarly, bidid is an optional response tracking ID for bidders.
// If specified, it can be included in the subsequent win notice call if the bidder wins.
// At least one seatbid object is required, which contains at least one bid for an impression.
// Other attributes are optional.
//
// To express a “no-bid”, the options are to return an empty response with HTTP 204. Alternately if the
// bidder wishes to convey to the exchange a reason for not bidding, just a BidResponse object is
// returned with a reason code in the nbr attribute.
// To express a “no-bid”, the options are to return an empty response with HTTP 204.
// Alternately if the bidder wishes to convey to the exchange a reason for not bidding, just a BidResponse object is returned with a reason code in the nbr attribute.
type BidResponse struct {
// Attribute:
+4 -5
View File
@@ -2,11 +2,10 @@ package openrtb
// 3.2.16 Object: Content
//
// This object describes the content in which the impression will appear, which may be syndicated or nonsyndicated
// content. This object may be useful when syndicated content contains impressions and does
// not necessarily match the publishers general content. The exchange might or might not have
// knowledge of the page where the content is running, as a result of the syndication method. For
// example might be a video impression embedded in an iframe on an unknown web property or device.
// This object describes the content in which the impression will appear, which may be syndicated or nonsyndicated content.
// This object may be useful when syndicated content contains impressions and does not necessarily match the publishers general content.
// The exchange might or might not have knowledge of the page where the content is running, as a result of the syndication method.
// For example might be a video impression embedded in an iframe on an unknown web property or device.
type Content struct {
// Attribute:
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.21 Object: Data
//
// The data and segment objects together allow additional data about the related object (e.g., user,
// content) to be specified. This data may be from multiple sources whether from the exchange itself or
// third parties as specified by the id field. A bid request can mix data objects from multiple providers.
// The data and segment objects together allow additional data about the related object (e.g., user, content) to be specified.
// This data may be from multiple sources whether from the exchange itself or third parties as specified by the id field.
// A bid request can mix data objects from multiple providers.
// The specific data providers in use should be published by the exchange a priori to its bidders.
type Data struct {
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.12 Object: Deal
//
// This object constitutes a specific deal that was struck a priori between a buyer and a seller. Its presence
// with the Pmp collection indicates that this impression is available under the terms of that deal. Refer to
// Section 7.3 for more details.
// This object constitutes a specific deal that was struck a priori between a buyer and a seller.
// Its presence with the Pmp collection indicates that this impression is available under the terms of that deal.
// Refer to Section 7.3 for more details.
type Deal struct {
// Attribute:
+9 -11
View File
@@ -2,19 +2,17 @@ package openrtb
// 3.2.18 Object: Device
//
// This object provides information pertaining to the device through which the user is interacting. Device
// information includes its hardware, platform, location, and carrier data. The device can refer to a mobile
// handset, a desktop computer, set top box, or other digital device.
// This object provides information pertaining to the device through which the user is interacting.
// Device information includes its hardware, platform, location, and carrier data.
// The device can refer to a mobile handset, a desktop computer, set top box, or other digital device.
//
// BEST PRACTICE: There are currently no prominent open source lists for device makes, models, operating
// systems, or carriers. Exchanges typically use commercial products or other proprietary lists for these
// attributes. Until suitable open standards are available, exchanges are highly encouraged to publish lists
// of their device make, model, operating system, and carrier values to bidders.
// BEST PRACTICE: There are currently no prominent open source lists for device makes, models, operating systems, or carriers.
// Exchanges typically use commercial products or other proprietary lists for these attributes.
// Until suitable open standards are available, exchanges are highly encouraged to publish lists of their device make, model, operating system, and carrier values to bidders.
//
// BEST PRACTICE: Proper device IP detection in mobile is not straightforward. Typically it involves starting
// at the left of the x-forwarded-for header, skipping private carrier networks (e.g., 10.x.x.x or
// 192.x.x.x), and possibly scanning for known carrier IP ranges. Exchanges are urged to research and
// implement this feature carefully when presenting device IP values to bidders.
// BEST PRACTICE: Proper device IP detection in mobile is not straightforward.
// Typically it involves starting at the left of the x-forwarded-for header, skipping private carrier networks (e.g., 10.x.x.x or 192.x.x.x), and possibly scanning for known carrier IP ranges.
// Exchanges are urged to research and implement this feature carefully when presenting device IP values to bidders.
type Device struct {
// Attribute:
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.10 Object: Format
//
// This object represents an allowed size (i.e., height and width combination) or Flex Ad parameters for a
// banner impression. These are typically used in an array where multiple sizes are permitted. It is
// recommended that either the w/h pair or the wratio/hratio/wmin set (i.e., for Flex Ads) be specified.
// This object represents an allowed size (i.e., height and width combination) or Flex Ad parameters for a banner impression.
// These are typically used in an array where multiple sizes are permitted.
// It is recommended that either the w/h pair or the wratio/hratio/wmin set (i.e., for Flex Ads) be specified.
type Format struct {
// Attribute:
+6 -6
View File
@@ -2,13 +2,13 @@ package openrtb
// 3.2.19 Object: Geo
//
// This object encapsulates various methods for specifying a geographic location. When subordinate to a
// Device object, it indicates the location of the device which can also be interpreted as the users current
// location. When subordinate to a User object, it indicates the location of the users home base (i.e., not
// necessarily their current location).
// This object encapsulates various methods for specifying a geographic location.
// When subordinate to a
// Device object, it indicates the location of the device which can also be interpreted as the users current location.
// When subordinate to a User object, it indicates the location of the users home base (i.e., not necessarily their current location).
//
// The lat/lon attributes should only be passed if they conform to the accuracy depicted in the type
// attribute. For example, the centroid of a geographic region such as postal code should not be passed.
// The lat/lon attributes should only be passed if they conform to the accuracy depicted in the type attribute.
// For example, the centroid of a geographic region such as postal code should not be passed.
type Geo struct {
// Attribute:
+6 -7
View File
@@ -2,14 +2,13 @@ package openrtb
// 3.2.4 Object: Imp
//
// This object describes an ad placement or impression being auctioned. A single bid request can include
// multiple Imp objects, a use case for which might be an exchange that supports selling all ad positions on
// a given page. Each Imp object has a required ID so that bids can reference them individually.
// This object describes an ad placement or impression being auctioned.
// A single bid request can include multiple Imp objects, a use case for which might be an exchange that supports selling all ad positions on a given page.
// Each Imp object has a required ID so that bids can reference them individually.
//
// The presence of Banner (Section 3.2.6), Video (Section 3.2.7), and/or Native (Section 3.2.9) objects
// subordinate to the Imp object indicates the type of impression being offered. The publisher can choose
// one such type which is the typical case or mix them at their discretion. However, any given bid for the
// impression must conform to one of the offered types.
// The presence of Banner (Section 3.2.6), Video (Section 3.2.7), and/or Native (Section 3.2.9) objects subordinate to the Imp object indicates the type of impression being offered.
// The publisher can choose one such type which is the typical case or mix them at their discretion.
// However, any given bid for the impression must conform to one of the offered types.
type Imp struct {
// Attribute:
+3 -4
View File
@@ -2,10 +2,9 @@ package openrtb
// 3.2.5 Object: Metric
//
// This object is associated with an impression as an array of metrics. These metrics can offer insight into
// the impression to assist with decisioning such as average recent viewability, click-through rate, etc. Each
// metric is identified by its type, reports the value of the metric, and optionally identifies the source or
// vendor measuring the value.
// This object is associated with an impression as an array of metrics.
// These metrics can offer insight into the impression to assist with decisioning such as average recent viewability, click-through rate, etc.
// Each metric is identified by its type, reports the value of the metric, and optionally identifies the source or vendor measuring the value.
type Metric struct {
// Attribute:
+10 -12
View File
@@ -2,20 +2,18 @@ package openrtb
// 3.2.9 Object: Native
//
// This object represents a native type impression. Native ad units are intended to blend seamlessly into
// the surrounding content (e.g., a sponsored Twitter or Facebook post). As such, the response must be
// well-structured to afford the publisher fine-grained control over rendering.
// This object represents a native type impression.
// Native ad units are intended to blend seamlessly into the surrounding content (e.g., a sponsored Twitter or Facebook post).
// As such, the response must be well-structured to afford the publisher fine-grained control over rendering.
//
// The Native Subcommittee has developed a companion specification to OpenRTB called the Dynamic
// Native Ads API. It defines the request parameters and response markup structure of native ad units.
// This object provides the means of transporting request parameters as an opaque string so that the
// specific parameters can evolve separately under the auspices of the Dynamic Native Ads API. Similarly,
// the ad markup served will be structured according to that specification.
// The Native Subcommittee has developed a companion specification to OpenRTB called the Dynamic Native Ads API.
// It defines the request parameters and response markup structure of native ad units.
// This object provides the means of transporting request parameters as an opaque string so that the specific parameters can evolve separately under the auspices of the Dynamic Native Ads API.
// Similarly, the ad markup served will be structured according to that specification.
//
// The presence of a Native as a subordinate of the Imp object indicates that this impression is offered as
// a native type impression. At the publishers discretion, that same impression may also be offered as
// banner, video, and/or audio by also including as Imp subordinates objects of those types. However, any
// given bid for the impression must conform to one of the offered types.
// The presence of a Native as a subordinate of the Imp object indicates that this impression is offered as a native type impression.
// At the publishers discretion, that same impression may also be offered as banner, video, and/or audio by also including as Imp subordinates objects of those types.
// However, any given bid for the impression must conform to one of the offered types.
type Native struct {
// Attribute:
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.11 Object: Pmp
//
// This object is the private marketplace container for direct deals between buyers and sellers that may
// pertain to this impression. The actual deals are represented as a collection of Deal objects. Refer to
// Section 7.3 for more details.
// This object is the private marketplace container for direct deals between buyers and sellers that may pertain to this impression.
// The actual deals are represented as a collection of Deal objects.
// Refer to Section 7.3 for more details.
type PMP struct {
// Attribute:
+2 -3
View File
@@ -2,9 +2,8 @@ package openrtb
// 3.2.17 Object: Producer
//
// This object defines the producer of the content in which the ad will be shown. This is particularly useful
// when the content is syndicated and may be distributed through different publishers and thus when the
// producer and publisher are not necessarily the same entity.
// This object defines the producer of the content in which the ad will be shown.
// This is particularly useful when the content is syndicated and may be distributed through different publishers and thus when the producer and publisher are not necessarily the same entity.
type Producer struct {
// Attribute:
+2 -2
View File
@@ -2,8 +2,8 @@ package openrtb
// 3.2.15 Object: Publisher
//
// This object describes the publisher of the media in which the ad will be displayed. The publisher is
// typically the seller in an OpenRTB transaction.
// This object describes the publisher of the media in which the ad will be displayed.
// The publisher is typically the seller in an OpenRTB transaction.
type Publisher struct {
// Attribute:
+2 -3
View File
@@ -2,9 +2,8 @@ package openrtb
// 3.2.3 Object: Regs
//
// This object contains any legal, governmental, or industry regulations that apply to the request. The
// coppa flag signals whether or not the request falls under the United States Federal Trade Commissions
// regulations for the United States Childrens Online Privacy Protection Act (“COPPA”).
// This object contains any legal, governmental, or industry regulations that apply to the request.
// The coppa flag signals whether or not the request falls under the United States Federal Trade Commissions regulations for the United States Childrens Online Privacy Protection Act (“COPPA”).
type Regs struct {
// Attribute:
+2 -4
View File
@@ -2,10 +2,8 @@ package openrtb
// 4.2.2 Object: SeatBid
//
// A bid response can contain multiple SeatBid objects, each on behalf of a different bidder seat and each
// containing one or more individual bids. If multiple impressions are presented in the request, the group
// attribute can be used to specify if a seat is willing to accept any impressions that it can win (default) or if
// it is only interested in winning any if it can win them all as a group.
// A bid response can contain multiple SeatBid objects, each on behalf of a different bidder seat and each containing one or more individual bids.
// If multiple impressions are presented in the request, the group attribute can be used to specify if a seat is willing to accept any impressions that it can win (default) or if it is only interested in winning any if it can win them all as a group.
type SeatBid struct {
// Attribute:
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.22 Object: Segment
//
// Segment objects are essentially key-value pairs that convey specific units of data. The parent Data
// object is a collection of such values from a given data provider. The specific segment names and value
// options must be published by the exchange a priori to its bidders.
// Segment objects are essentially key-value pairs that convey specific units of data.
// The parent Data object is a collection of such values from a given data provider.
// The specific segment names and value options must be published by the exchange a priori to its bidders.
type Segment struct {
// Attribute:
+3 -3
View File
@@ -2,9 +2,9 @@ package openrtb
// 3.2.13 Object: Site
//
// This object should be included if the ad supported content is a website as opposed to a non-browser
// application. A bid request must not contain both a Site and an App object. At a minimum, it is useful
// to provide a site ID or page URL, but this is not strictly required.
// This object should be included if the ad supported content is a website as opposed to a non-browser application.
// A bid request must not contain both a Site and an App object.
// At a minimum, it is useful to provide a site ID or page URL, but this is not strictly required.
type Site struct {
// Attribute:
+3 -5
View File
@@ -2,11 +2,9 @@ package openrtb
// 3.2.2 Object: Source
//
// This object describes the nature and behavior of the entity that is the source of the bid request
// upstream from the exchange. The primary purpose of this object is to define post-auction or upstream
// decisioning when the exchange itself does not control the final decision. A common example of this is
// header bidding, but it can also apply to upstream server entities such as another RTB exchange, a
// mediation platform, or an ad server combines direct campaigns with 3rd party demand in decisioning.
// This object describes the nature and behavior of the entity that is the source of the bid request upstream from the exchange.
// The primary purpose of this object is to define post-auction or upstream decisioning when the exchange itself does not control the final decision.
// A common example of this is header bidding, but it can also apply to upstream server entities such as another RTB exchange, a mediation platform, or an ad server combines direct campaigns with 3rd party demand in decisioning.
type Source struct {
// Attribute:
+3 -4
View File
@@ -2,10 +2,9 @@ package openrtb
// 3.2.20 Object: User
//
// This object contains information known or derived about the human user of the device (i.e., the
// audience for advertising). The user id is an exchange artifact and may be subject to rotation or other
// privacy policies. However, this user ID must be stable long enough to serve reasonably as the basis for
// frequency capping and retargeting.
// This object contains information known or derived about the human user of the device (i.e., the audience for advertising).
// The user id is an exchange artifact and may be subject to rotation or other privacy policies.
// However, this user ID must be stable long enough to serve reasonably as the basis for frequency capping and retargeting.
type User struct {
// Attribute:
+7 -9
View File
@@ -2,16 +2,14 @@ package openrtb
// 3.2.7 Object: Video
//
// This object represents an in-stream video impression. Many of the fields are non-essential for minimally
// viable transactions, but are included to offer fine control when needed. Video in OpenRTB generally
// assumes compliance with the VAST standard. As such, the notion of companion ads is supported by
// optionally including an array of Banner objects (refer to the Banner object in Section 3.2.6) that define
// these companion ads.
// This object represents an in-stream video impression.
// Many of the fields are non-essential for minimally viable transactions, but are included to offer fine control when needed.
// Video in OpenRTB generally assumes compliance with the VAST standard.
// As such, the notion of companion ads is supported by optionally including an array of Banner objects (refer to the Banner object in Section 3.2.6) that define these companion ads.
//
// The presence of a Video as a subordinate of the Imp object indicates that this impression is offered as a
// video type impression. At the publishers discretion, that same impression may also be offered as
// banner, audio, and/or native by also including as Imp subordinates objects of those types. However,
// any given bid for the impression must conform to one of the offered types
// The presence of a Video as a subordinate of the Imp object indicates that this impression is offered as a video type impression.
// At the publishers discretion, that same impression may also be offered as banner, audio, and/or native by also including as Imp subordinates objects of those types.
// However, any given bid for the impression must conform to one of the offered types.
type Video struct {
// Attribute: