MD SP Adi2.0 As I03 070105

Metadata 2.
0 Specifications
ADI 2.0 Specification Asset Structure
MD-SP-ADI2.0-AS-I03-070105
ISSUED
Notice
This Metadata specification is the result of a cooperative effort
undertaken at the direction of Cable Television Laboratories, Inc. for the
benefit of the cable industry and its customers. This document may
contain references to other documents not owned or controlled by
CableLabs. Use and understanding of this document may require
access to such other documents. Designing, manufacturing, distributing,
using, selling, or servicing products, or providing services, based on this
document may require intellectual property licenses from third parties for
technology referenced in this document.
Neither CableLabs nor any member company is responsible to any party

for any liability of any nature whatsoever resulting from or arising out of
use or reliance upon this document, or any document referenced herein.
This document is furnished on an "AS IS" basis and neither CableLabs
nor its members provides any representation or warranty, express or
implied, regarding the accuracy, completeness, noninfringement, or
fitness for a particular purpose of this document, or any document
referenced herein.
© Copyright 2004-2007 Cable Television Laboratories, Inc.
All rights reserved.
MD-SP-ADI2.0-AS-I03-070105 Metadata 2.0 Specifications
Document Status Sheet
Document Control Number: MD-SP-ADI2.0-AS-I03-070105
Document Title: ADI 2.0 Specification Asset Structure
Revision History: I01 - Issued 12/10/04
I02 - Issued 5/5/06
I03 - Issued 1/5/07
Date: January 5, 2007
Status: WIP Draft Issued Closed
Distribution Restrictions: Author Only CL/Member CL/ Member/ Public

Vendor
Key to Document Status Codes:
Work in Progress An incomplete document, designed to guide discussion and generate

feedback that may include several alternative requirements for
consideration.
Draft A document in specification format considered largely complete, but

lacking review by Members and vendors. Drafts are susceptible to
substantial change during the review process.
Issued A stable document, which has undergone rigorous member and vendor
review and is suitable for product design and development, cross-vendor
interoperability, and for certification testing.
Closed A static document, reviewed, tested, validated, and closed to further
engineering change requests to the specification through CableLabs.
Trademarks:
DOCSIS®, eDOCSIS™, M-CMTS™, PacketCable™, CableHome®, CableOffice™, OpenCable™,

CableCARD™, DCAS™, OCAP™, and CableLabs® are trademarks of Cable Television Laboratories, Inc.
®
ii CableLabs 1/05/07
ADI 2.0 Specification Asset Structure MD-SP-ADI2.0-AS-I03-070105
Contents
1 SCOPE..................................................................................................................................................................1
1.1 Introduction and Overview............................................................................................................................1
1.2 Purpose of document .....................................................................................................................................1
1.3 Organization of document .............................................................................................................................1
1.4 Requirements .................................................................................................................................................2
2 REFERENCES ....................................................................................................................................................3
2.1 Normative References ...................................................................................................................................3
2.2 Informative References..................................................................................................................................3
2.3 Reference Acquisition ...................................................................................................................................3
3 TERMS AND DEFINITIONS ............................................................................................................................5
4 ABBREVIATIONS AND ACRONYMS............................................................................................................6
5 ADI 2.0..................................................................................................................................................................7
5.1 Introduction ...................................................................................................................................................7
5.2 Asset structure ...............................................................................................................................................7
5.2.1 COMMON ASSET ELEMENTS .....................................................................................................................7
5.2.2 ASSET OPERATIONS ..................................................................................................................................8
5.2.3 GROUP ASSET ..........................................................................................................................................8
5.2.4 METADATA ASSET ..................................................................................................................................10
5.2.5 CONTENT ASSET ....................................................................................................................................12
5.3 The AssociateContent Signal.......................................................................................................................15
5.4 Relationships Between Assets .....................................................................................................................16
5.4.1 GROUP MEMBERSHIP.............................................................................................................................16
5.4.2 REFERENCE ...........................................................................................................................................16
5.5 Asset Updates ..............................................................................................................................................18
5.6 ADI Documents...........................................................................................................................................18
5.6.1 MEANS OF TRANSMISSION ......................................................................................................................18
5.6.2 MESSAGE DOCUMENT STRUCTURE .........................................................................................................19
5.6.3 ASSET DISTRIBUTION INTERFACE (ADI2)................................................................................................20
5.6.4 DELIVERY ACKNOWLEDGEMENT (ACK)..................................................................................................20
5.7 Schema.........................................................................................................................................................23
5.7.1 DOCUMENT VALIDATION ........................................................................................................................23
5.7.2 SCHEMA SEPARATION.............................................................................................................................23
5.7.3 XML NAMESPACES ................................................................................................................................24
APPENDIX I ADI 1.1 COMPARISON (INFORMATIVE) ..............................................................................25
APPENDIX II AMS RE-DISTRIBUTION (INFORMATIVE) ......................................................................28
APPENDIX III DERIVED FILES (INFORMATIVE)......................................................................................29

5.8 Provider's Content Asset..............................................................................................................................29
5.9 MSO-Produced Content Asset.....................................................................................................................29
APPENDIX IV REVISION HISTORY ..............................................................................................................31
®
1/05/07 CableLabs iii
Tables
Table 1 - Common Asset Element Fields ......................................................................................................................7
Table 2 - Group Asset Operation Types and Fields ......................................................................................................9
Table 3 - Metadata Asset Operation Types and Fields................................................................................................10
Table 4 - Content Asset Operation Types and Fields ..................................................................................................13
Table 5 - AssociateContent Signal ..............................................................................................................................15
Table 6 - Reference Element .......................................................................................................................................17
Table 7 - Common Document Element and Attributes ...............................................................................................19
Table 8 - Acknowledgement Element fields ...............................................................................................................20
Table 9 - Document Status Values ..............................................................................................................................23
®
iv CableLabs 1/05/07
1 SCOPE
1.1 Introduction and Overview
The Asset Distribution Interface documents are the means by which assets (content as well as metadata describing
the content or offer) are transported from a provider to an Asset Management System, a logical entity. In addition, it
provides a basic degree of management through ADI Mechanisms of the assets and previously distributed assets.
• The Asset Distribution Interface (ADI) Asset Structure specification defines the following:
• Messages that distribute assets from providers to MSOs and between MSO locations and sub-systems.
• Messages that of distribution acknowledgement of receipt.
• The term "ADI 2.0" is used to include both the common asset structure and all the application fields in the
assets.
• Applications will be documented in a number of ADI2.0 Application documents, one for each specific
application, e.g., "VOD", "Games". These documents will define the assets used by the application, the fields,
the semantics and rules of usage of the asset.
• The relationship between the ADI 2.0 Asset structure and the ADI 2.0 Application documents is that the
common asset structure acts as a medium to manage the delivery of the assets of each application.
Both the ADI 2.0 Asset structure document and each of the ADI 2.0 Application documents will have companion
reference documents which include the following.
• XML Schema definition – This is an xsd file that can be used as the foundation for a specific application's
schema hierarchy.
• Content characteristic specifications – These types of documents contains content encoding specifications, etc.
1.2 Purpose of document
This document specifies the fundamental common asset structure used to convey data describing content in the
context of ADI. It also specifies messages used to acknowledge receipt of assets.
It does not describe application specific information, content characteristics, or business rules surrounding delivery.
1.3 Organization of document
The document starts out specifying the general kinds of assets (GroupAsset, MetadataAsset, ContentAsset) and
operations that can be done on those assets. Then it describes the kinds of relationships that can occur between these
assets. After this, the specification describes the ADI2.0 wrapper document to contain these messages to distribute
or structure the assets or to contain a delivery acknowledgement of the ADI2.0 document received. The last section
talks about describing the purposes and constraints of a schema to functionally embody the structures defined in this
document. An informative appendix describes how ADI 1.1 types of structure might map into an ADI 2.0 structure
using a VOD-like application as an example. Parts of this example are also used within the document to point out
concepts. Examples should not imply more than free interpretation concepts.
®
1/05/07 CableLabs 1
1.4 Requirements
Throughout this document, the words that are used to define the significance of particular requirements are
capitalized. These words are:
"MUST" This word means that the item is an absolute requirement of this specification.
"MUST NOT" This phrase means that the item is an absolute prohibition of this specification.
"SHOULD" This word means that there may exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case carefully weighed before
choosing a different course.
"SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the
listed behavior is acceptable or even useful, but the full implications should be understood
and the case carefully weighed before implementing any behavior described with this label.
"MAY" This word means that this item is truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it enhances the product, for example;
another vendor may omit the same item.
®
2 CableLabs 1/05/07
2 REFERENCES
2.1 Normative References
In order to claim compliance with this specification, it is necessary to conform to the following standards and other
works as indicated, in addition to the other requirements of this specification. Notwithstanding, intellectual property
rights may be required to use or implement such normative references.
[XML] W3C REC: eXtensible Markup Language (XML) 1.1, February 4, 2004.
[STD0013] IETF STD0013 (RFC 1035), Domain Names-Implementation and Specification (November
1987).
[RFC 1321] IETF RFC 1321, The MD5 Message-Digest Algorithm (April 1992).
[RFC 3629] IETF RFC 3629, UTF-8 A Transformation Format of ISO 10646, November 2003.
[RFC 2616] IETF RFC 2616, HyperText Transfer Protocol—HTTP/1.1, June 1999.
[RFC 2396] IETF RFC 2396, Uniform Resource Identifiers (URI) : Generic Syntax, August 1998.
[RFC 1738] IETF RFC 1738, Uniform Resource Locators (URL), December 1994.
2.2 Informative References

[MSG Schema] CableLabs ADI2.0 Example MSG Schema Definition;
http://www.cablelabs.com/projects/metadata/specifications/specifications20.html
[Core Schema] CableLabs ADI2.0 Example ADI Core Schema Definition;
http://www.cablelabs.com/projects/metadata/specifications/specifications20.html
[VOD-CEP] CableLabs Video-on-Demand Content Encoding Profiles Specification, MD-SP-VOD-CEP2.0-
I02-070105, January 5, 2007, Cable Television Laboratories, Inc.
[RFC 2660] IETF RFC 2660, The Secure HyperText Transfer Protocol, August 1999.
[RFC 3208] IETF RFC 3208, PGM Reliable Transport Protocol Specification, December 2001.
[CONTENT 1.1] CableLabs Video-on-Demand Content Specification Version 1.1, MD-SP-VOD-CONTENT1.1-
I05-060831, August 31, 2006, Cable Television Laboratories, Inc.
[ADI 1.1] CableLabs Asset Distribution Interface Specification Version 1.1, MD-SP-ADI1.1-I04-060505,
May 5, 2006, Cable Television Laboratories, Inc.
2.3 Reference Acquisition
CableLabs Specifications:
• Cable Television Laboratories, Inc. (CableLabs), 858 Coal Creek Circle, Louisville, CO 80027,
www.cablelabs.com/projects/metadata
IETF Specifications:
• Internet Engineering Task Force (IETF) Secretariat, c/o Corporation for National Research Initiatives,
1895 Preston White Drive, Suite 100, Reston, VA 20191-5434, Phone 703-620-8990, Fax 703-620-9071,
Internet: www.ietf.org
®
1/05/07 CableLabs 3
XML Specifications:
• Worldwide Web Consortium, http://www.w3c.org
ISO Specifications:
• ISO Central Secretariat: International Organization for Standardization (ISO), 1, rue de Varembe, Case
postale 56, CH-1211 Geneva 20, Switzerland; Internet: http://ww.iso.ch/
®
4 CableLabs 1/05/07
3 TERMS AND DEFINITIONS
This specification uses the following terms:
Alpha(4)Num(16) Format to indicate 4 initial alpha characters proceeding 16 numeric characters.
AMS Asset Management System. A role played by any logical entity functioning as the
receiving point of a delivery.
ASCII The subset of Unicode characters comprising U+0000 to U+007F, inclusive.
ASCII(1-255) 1 to 255 ASCII characters.
Delivery The transmission of data or content to a recipient.
Hexadecimal (32) 32 Hexadecimal characters.
Message Document An XML document containing one or more ADI messages.

Numeric (64 bits) Extended numeric format to allow for very large numbers whose value range can be
represented by 64 bits.
OS Independent File For specification only - definition of filename is unrestricted, as filename sizes continue to
Name expand. There is a reasonable expected size of no greater than 128-byte name, but
documents containing filenames greater than 128 bytes are valid. Valid characters are
uppercase and lowercase letters, digits, the underscore (_), the hyphen (-), and the period
(.).
Provider A Party responsible for allocating asset identifiers.
Sender A Party transmitting content and metadata, which may or may not be the same as a
Provider.
UNICODE The international character set for languages requiring characters beyond the scope of US-
ASCII (U+000-U+007F) encoded in UTF-8, 16, or 32. For this document Unicode is
encoded in UTF-8 only.
UTF-8 (Unicode Transformation Format-8) is an octet (8-bit) lossless encoding of Unicode

characters. UTF-8 is interpreted as a sequence of bytes (up to 4), where the number of
octets depends on the integer value assigned to the Unicode character. The UTF-8
encoding is defined in ISO 10646-1:2000 Annex D or RFC 3629.
X(1-25) Format to indicate should contain from 1-25 alphanumeric characters.
XML Date Time The date and time representation specified in ISO 8601.
®
1/05/07 CableLabs 5
4 ABBREVIATIONS AND ACRONYMS
This specification uses the following abbreviations:
ACK Acknowledgement
ADI Asset Distribution Interface
AMS Asset Management System
CA Content Asset
FTP File Transfer Protocol
GA Group Asset
HTTP HyperText Transfer Protocol
HTTPS HyperText Transfer Protocol Secure
ID Identification
MA Metadata Asset
MoD Movies-on-Demand
MSO Multiple System Operator
PGM Pragmatic General Multicast
SD Standard Definition
STB Set Top Box
TBD To Be Determined
UI User Interface
URI Uniform Resource Identifier
UTF Unicode Transformational Format
VoD Video-on-Demand
W3C Worldwide Web Consortium
XML eXtensible Markup Language
®
6 CableLabs 1/05/07
5 ADI 2.0
5.1 Introduction
ADI 2.0 uses the following basic concepts:

• Group Assets
• Metadata Assets
• Content Assets
5.2 Asset structure
Refer to Appendix I for a better understanding of the elements defined in tables in this chapter.
5.2.1 Common Asset Elements
All assets share the following common attributes and MUST contain at a minimum, the Required fields as defined
in Table 1:
Table 1 - Common Asset Element Fields
Element Attribute Definition Values Required

[ElementName] The specific element name, e.g., ASCII, REQUIRED
Title, Movie, Posterboard, UpperCamelCase,
Category… initial Alpha
providerID A unique identifier for the provider The domain name of REQUIRED
of the Asset. The providerID MUST the provider.
be set to a registered Internet ASCII X(1-20)
domain name restricted to at most
20 lower-case characters and
belonging to the provider. For
example a valid providerID for
CableLabs is "cablelabs-films.com"
(19 chars).
assetID An identifier for the asset that is ASCII String of 20 REQUIRED
unique within a provider's assetID characters.
space. The unique portable Alpha(4)Num(16)
identification of an asset is the
combination of its providerID and
assetID.
updateNum Update sequence number for Asset Numeric REQUIRED
replacement.
groupAsset Optional element that defines an String "Y" or "N" OPTIONAL
asset as a group asset.
AssetLifetime Defines the temporal context for a REQUIRED
(Child of Asset given asset.
element)
®
1/05/07 CableLabs 7

startDateTime Date and time when the Asset XML Date Time REQUIRED
begins its life.
endDateTime Date and time when the Asset ends XML Date Time REQUIRED
its life.
The definition and values of these common attributes will not be repeated in subsequent tables.
An asset is a unique entity. It is identified uniquely by its providerID/assetID, thus there is only one asset with a
given providerID/assetID in the whole universe of assets distributed by ADI. Each asset of any type has an Asset
Lifetime.
The updateNum attribute is a sequence number for updates of an Asset. An asset is subject to complete replacement.
Therefore, receiving an asset message with lower updateNum number than already received may be ignored and
receiving an asset message with any higher updateNum number than already received MUST replace the asset with
the new message.
Assets may have additional attributes and elements as defined by the Application specification that governs the use
of assets of a particular type.
5.2.2 Asset Operations
Information about Assets is conveyed in messages, which comprise an "envelope" specifying the operation
applicable to the enclosed data. In the following example in this XML fragment, <OpenGroupAsset> is the
envelope element:
...
<adi:OpenGroupAsset type="VODRelease" product="VOD">
<vod:VODRelease
providerID="warnerbros.com"
assetID="TVNX7459000000000001"
updateNum="1"
groupAsset="Y">
<adi:AssetLifetime
startDateTime="2004-04-15T00:00:00"
endDateTime="2004-04-15T00:00:00" />
</vod:VODRelease>
</adi:OpenGroupAsset>
...
Note that the type attribute of the <OpenGroupAsset> element MUST be identical to the name of the element
containing the asset data: "VODRelease". This small redundancy allows the envelope to be processed at the AMS
level, and the message to be routed to the application(s) concerned.
5.2.3 Group Asset
The Group Asset is the organizing principle for Asset Distribution, for example all the Metadata assets of an VOD
distribution belong to the same "VODRelease" group.
Metadata assets MUST be grouped by having a common owner -- a distinguished asset called GroupAsset. A
GroupAsset is distinguished from other types of assets in that it is:
the owner of metadata assets.

not a member of any group.
A GroupAsset of a given type MAY be the owner of Assets of only certain predetermined types. The particular
member types allowed for a particular type of GroupAsset is defined in application scope.
®
8 CableLabs 1/05/07
A GroupAsset contains data values specific to its type as defined in the relevant application specification and
MUST contain at a minimum, the Required fields as defined in Table 2.
Table 2 - Group Asset Operation Types and Fields

OpenGroupAsset, GroupAsset control and ASCII, enumerated REQUIRED
DropGroupAsset, delivery container. as operation
CloseGroupAsset, Element names.
ReplaceGroupAsset
type The type of GroupAsset. The ASCII value REQUIRED
must be equal to
the [Element
Name] that follows.
product The product, or application ASCII X(1-32) REQUIRED
for the group, e.g., "MOD",
"Game"…
[ElementName] common common REQUIRED
(child of GA
operation)
providerID common common REQUIRED
assetID common common REQUIRED
updateNum common common OMITTED for
DropGroupAsset;
REQUIRED for
other operations
groupAsset common common OPTIONAL
AssetLifetime Defines the temporal REQUIRED for
(child of context for a given asset. OpenGroupAsset
[ElementName]) and
startDateTim common common ReplaceGroupAsset;
e OMITTED for other
operations
endDateTime common common
(data specific to
assets of this type)
The different envelope elements have the following semantics:

• OpenGroupAsset: Creates a GroupAsset of the specified type and populates it with the enclosed data specific
to GroupAssets of this type contained in the incoming message. It implies it also creates the "group", i.e., assets
cannot be introduced into a group before a GroupAsset is created to be their owner. Performing this operation
on an already existing GroupAsset is not allowed.
• DropGroupAsset: Deletes the GroupAsset and all the MetadataAssets in the group. It has the same effect as
exceeding the endDateTime of the AssetLifetime.
• CloseGroupAsset: This is a "hint" from the provider that the group has received a "complete" set of assets. It
excludes neither replacing members that have already been created, nor adding new member assets, unless
these restrictions are imposed by Application specification.
®
1/05/07 CableLabs 9
• ReplaceGroupAsset: Replaces a GroupAsset with the incoming asset message. All attributes and sub-elements
of the asset are replaced with the inbound structure during this operation (provided that the replacing
updateNum is greater than the current value). Performing this operation on a GroupAsset that does not yet exist
is not allowed.
Note that Groups are potentially quite diverse. Application specifications may define groups that are very long-
lived, with a constantly changing membership, or conversely very short-lived groups with few or no members.
XML Fragment Example for Open:

...
<adi:OpenGroupAsset type="VODRelease" product="VOD">
<vod:VODRelease
assetID="TVNX7459000000000001"
updateNum="1"
groupAsset="Y">
<adi:AssetLifetime
endDateTime="2005-04-15T00:00:00"/>
</vod:VODRelease>
</adi:OpenGroupAsset>
...
5.2.4 Metadata Asset
A MetadataAsset instance MUST only be the member of a single GroupAsset instance and cannot be re-assigned to
a different GroupAsset instance. Application Specifications define the allowed Member Types for a given Group
type.
A MetadataAsset contains data values specific to its type and MUST contain at a minimum, the Required fields as
defined in Table 3.
Table 3 - Metadata Asset Operation Types and Fields

AddMetadataAsset, MetadataAsset ASCII, REQUIRED
RemoveMetadataAsset, control and delivery enumerated as
ReplaceMetadataAsset container. operation Element
names.
type The type of The ASCII value REQUIRED
MetadataAsset. must be equal to
the [AssetName]
that follows.
product The product, or ASCII X(1-32) REQUIRED
application for the
group, e.g., "MOD",
"Games"…
groupProviderID common common REQUIRED for
(providerID) (providerID) AddMetdataAsset;
OMITTED for other
operations
groupAssetID common (assetID) common (assetID) REQUIRED for
AddMetadataAsset;
OMITTED for other
operations
®
10 CableLabs 1/05/07

(child of MetadataAsset
operation)
RemoveMetadataAsset;
REQUIRED for other
operations
AssetLifetime common common OMITTED for
(child of RemoveMetadataAsset;
[ElementName]) REQUIRED for other
operations
startDateTime common common
(data specific to assets
of this type)
The different envelope elements have the following semantics:

• AddMetadataAsset: Creates a MetadataAsset and populates it with the content of the incoming asset message.
Performing this operation on an already existing MetadataAsset is not allowed.
• RemoveMetadataAsset: Deletes the MetadataAsset. It has the same effect as exceeding the endDateTime of
the AssetLifetime.
• ReplaceMetadataAsset: Replaces an existing MetadataAsset with the incoming asset message data. All
attributes and sub-elements of the asset are replaced with the inbound structure during this operation (provided
that the replacing updateNum is greater than the current value). Performing this operation on a MetadataAsset
that does not yet exist is not allowed.
It is expected that both "Remove" and "Replace" are constructs for use in correcting errors. The preferred method by
which one set of data is replaced by another is to have Metadata assets with appropriate time/date intervals in the
data to control the time/date validity of other data. Additionally because a MetadataAsset cannot be reassigned to a
different GroupAsset, these constructs should not be used for this purpose.
XML Fragment Example for Add:

...
<adi:AddMetadataAsset
groupProviderID="warnerbros.com" groupAssetID="TVNX7459000000000001">
type="Terms" product="VOD"
<vod:Terms
format="SD"
assetID="TVNX745900000000102"
updateNum="1" >
<adi:AssetLifetime
endDateTime="2005-04-15T00:00:00"/>
<vod:PreviewPeriod>0</vod:PreviewPeriod>
<vod:RentalPeriod>00:00:00</vod:RentalPeriod>
<vod:SuggestedPrice currency="USD">4.99</vod:SuggestedPrice>
<vod:BillingID>74590</vod:BillingID>
<vod:DistributorName>TNV</vod:DistributorName>
<vod:DistributorRoyaltyPercentage>0.00</vod:DistributorRoyaltyPercentage>
®
1/05/07 CableLabs 11
<vod:DistributorRoyaltyMinimum>0.00</vod:DistributorRoyaltyMinimum>
<vod:TargetFileSet type="MPEG2SD">
<vod:LanguageSet audio="en" subtitle="en">
<vod:ShowPart partNbr="1"/>
<vod:ContentRef
assetID="TVNX745900000000101"
</vod:ShowPart>
</vod:LanguageSet>
</vod:TargetFileSet>
</vod:Terms>
</adi:AddMetadataAsset>
...
5.2.5 Content Asset
A ContentAsset combines metadata and a physical file which are transmitted "together".
A ContentAsset may be transmitted independently of any GroupAsset. This allows building a library of
ContentAssets and files independently of the Groups which may use them.
A Content Asset is shared / re-used to the extent that multiple Metadata Assets reference it. For example, a
promotional still image might be displayed in an STB Guide UI, or via some ETV "Managed Content", or on an
MSO Web Site. In each case there may be distinct Metadata Assets, in 2 or 3 different types of Groups, which
inform the relevant applications of the identity of the ContentAsset containing the particular image.
A ContentAsset contains data values specific to its type and MUST contain at a minimum, the Required fields as
defined in Table 4.
®
Table 4 - Content Asset Operation Types and Fields

AcceptContentAsset, ContentAsset control ASCII, REQUIRED
DestroyContentAsset, and delivery enumerated as
ReplaceContentAsset container. operation
Element names
type The type of The ASCII REQUIRED
ContentAsset. value must be
equal to the
[ElementName]
that follows.
metadataOnly ContentAsset flag to String "Y" or OPTIONAL for
allow for Content "N" AcceptContentAsset
metadata to be and
delivered without ReplaceContentAsset,
content. OMITTED for
DestroyContentAsset
fileName Name of the content ASCII REQUIRED, if
file. Expected to be Content File is present
128.
Must be OS
independent.
fileSize Size of the content file Numeric (64 "
in bytes. bits)
mD5CheckSum MD5 checksum of the Hexadecimal "
content file, as (32).
lowercase
hexadecimal digits.
tranferContentURL URL to obtain content URL OPTIONAL
file. The URL scheme
must be "ftp" or "http"
or 'https' or "file" or
"pgm"
(child of Content
Asset operation)
DestroyContentAsset;
REQUIRED for other
operations
assetAckTo An optional URL to URL OPTIONAL
which a separate
acknowledgement for
events in the asset
may be posted
®

AssetLifetime common common OMITTED for
(child of DestroyContentAsset;
[ElementName]) REQUIRED for other
startDateTime common common operations

(data specific to
assets of this type)
The different elements which bracket a ContentAsset have the following semantics:
• AcceptContentAsset: Creates a ContentAsset unrelated to any GroupAsset and populates it with the content of
the incoming asset message. Performing this operation on an already existing ContentAsset is not allowed.
• DestroyContentAsset: Deletes the ContentAsset and all content files for the asset. It has the same effect as
exceeding the endDateTime of the AssetLifetime.
• ReplaceContentAsset: Replaces an existing ContentAsset with the incoming asset message including any
accompanying content file. Performing this operation on a ContentAsset that does not yet exist is not allowed.
XML Fragment Example for Accept:

...
<adi:AcceptContentAsset type="Video""
metaDataOnly="N"
fileName="analyzethatcombo.mpg"
fileSize="5616346216"
mD5CheckSum="bd11596299d5fe551e9f47e38dca5a70"
<vod:Video
assetID="TVNX74590000000010"
updateNum="1"
filename=" analyzethatcombo.mpg"
filesize="5616346216"
encodingProfile="MPEG2SD">
<adi:AssetLifetime
endDateTime="2005-04-15T00:00:00"/>
<vod:Description>MPEG SD for AnalyzeThis/That combo</vod:Description>
<vod:EncryptionRequired>NONE</vod:EncryptionRequired>
<vod:RunTime>03:24:16</vod:RunTime>
<vod:AudioType languageCode="en"
PID="0x1E2>DolbyDigital</vod:AudioType>
</vod:Video>
</adi:AcceptContentAsset>
...
To allow for the ADI receiving module to have an option to perform a "gross" level validation of the content file,
checksum and file size information are placed at the ADI level if a content file is already linked. This approach
provides a number of significant operational enhancements:
• ADI level modules do not require knowledge of application-specific syntax.
• Immediate feedback of transfer validity can be returned to the sending component of transfer.
• New Content types can be added without a rewrite of the "gross level" validation modules.
• ADI receivers need only "route" content files, not have knowledge of their type, format, etc.
®
To emulate the simple behavior of [ADI 1.1], where the Movie is deleted at the same time as the VODRelease is
deleted when the window expires, the VODRelease GroupAsset and the associated ContentAsset SHOULD be
given the same AssetLifetime. That way the lifetimes expire simultaneously:
• The GroupAsset and the member metadata assets are deleted (or some semantic equivalent) at the end of the
GroupAsset lifetime.
• The ContentAsset is deleted at the end of its lifetime along with all content files for the asset.
5.3 The AssociateContent Signal
The AssociateContent signal provides a mechanism for Providers to inform an AMS that a particular Content Asset
is in some way associated to a particular Group Asset. A Content Asset may be associated with multiple Group
Assets and a Group Asset may be associated with multiple Content Assets. There are no ADI implications of this
relationship.
Content Files are not bound to any particular Group when they are transmitted by a Provider; they may in fact be
stored in a Content Library system and subsequently used by many Groups.
The AssociateContent signal provides a mechanism for Providers to inform an AMS that a particular content file is
of significance to a particular Group. The AMS may then evaluate its dispatching rules, and initiate a multicast
transfer if there are multiple recipients. The primary motivation is to reduce use of time/bandwidth by using a
multicast protocol to transfer large content files to multiple recipients.
The AssociateContent signal contains data values specific to its type and MUST contain at a minimum, the
Required fields as defined in Table 5.
Table 5 - AssociateContent Signal

AssociateContent Signal to evaluate ASCII, enumerated as
operation Element names
type The type of The ASCII value must be REQUIRED
ContentAsset that is to equal to the [Element Name]
be associated. that follows.
effectiveDate Suggested date when XML Date Time OPTIONAL
associate content signal
should be used
groupProviderID Group Identifier common REQUIRED
groupAssetID " " common REQUIRED
XML Fragment Example for AssociateContent:

...
<adi:AssociateContent type="Video"
effectiveDate="2004-12-01T00:00:00"
groupProviderID="warnerbros.com"
groupAssetID="TVNX7459000000000001"
assetID="TVNX745900000000101"
/>
®
...
5.4 Relationships Between Assets
The particular GroupAsset and MetadataAsset types and data specific to these types will be defined in ADI
application documents, the relationships between assets are defined in this section.
ADI provides two linking mechanisms to enable Applications to construct the logical run-time data structures they
use to affect their functionality. These mechanisms are Group Membership and Reference. Another linking
mechanism is the AssociateContent Signal which assists in the physical distribution of content assets, but does not
assist in constructing logical data structures.
5.4.1 Group Membership
A particular (instance) MetadataAsset MUST be a member of one and only one GroupAsset. The delivery of a
GroupAsset MUST occur before any Metadata Asset is added to the group. Conversely, a MetadataAsset may be
delivered days (or months for a long-lived group) after its owner GroupAsset.
A MetadataAsset can become a member of the GroupAsset through the AddMetadataAsset operation and can
change its status in that group through the other metadata operations as described in Section 5.2.4.
An AMS maintains knowledge of the Common Asset Elements, defined in Section 5.2.1, for a GroupAsset and for
the particular metadata assets belonging to the group. This is sufficient to distribute and manage assets without
further application specific knowledge.
The AssetLifetime of a GroupAsset overrides the lifetime attributes of member assets, in that no member asset is
valid prior to the "startDateTime" or after the "endDateTime" attributes of the asset. Conversely, within the lifetime
bounds of the GroupAsset, a member asset is valid only within the period of its own AssetLifetime.
Implication: When a GroupAsset expires, its entire set of component MetadataAssets expires as well.
5.4.2 Reference
An Application uses the data conveyed in metadata assets. This data may include the identity of other assets, in the
form of the pair of values for a providerID and an assetID. It is convenient to express this idea as "one asset
References" or "has a Reference to" another asset. Typically content assets can be linked to a metadata asset through
this reference mechanism. Note that the scope of a reference is "global", since IDs are unique throughout all uses of
ADI. In particular references may span groups, and a reference to a group implicitly provides a link to all members
of the group.
References can be modified or removed through an update of the asset that contains the reference. It should be
noted that an asset is subject to complete replacement so all references contained in the asset need to be included
when an update is made.
Elements that are References shall be represented in appropriate XML schemas by having or extending the
ReferenceType complex type in the core ADI2 schema and MUST at a minimum contain the Required fields as
defined in Table 6.
®
Table 6 - Reference Element

[Reference element name] Name of XML element ASCII,
e.g., ContentRef having or extending the UpperCamelCase,
ReferenceType complex type initial Alpha.
in the core ADI2 schema.
amsValidate If true, this reference should String "Y" or "N" OPTIONAL
be validated by the AMS.
In the following Terms asset XML Fragment example, the element ContentRef is used to reference the appropriate
Content Asset:
...
<vod:Terms format="SD" providerID="warnerbros.com"

assetID="TVNX745900000000102"
updateNum="1">
<adi:AssetLifetime
endDateTime="2005-04-15T00:00:00"/>
<vod:PreviewPeriod>0</vod:previewPeriod>
<vod:RentalPeriod>00:00:00</vod:rentalPeriod>
<vod:DistributorName>TVN</vod:DistributorName>
<vod:DistributorRoyaltyMiminum>0.00</vod: DistributorRoyaltyMiminum>
<vod:LanguageSet audio="en" subtitle="en"
<vod:ShowPart partNbr="1">
<vod:ContentRef
assetID="TVNX745900000000101" />
</vod:ShowPart>
</vod:LanguageSet>
</vod:terms>
...
This form of reference is transparent to an AMS without application-specific logic.
5.4.2.1 AMS Validated Reference
An AMS validated reference conveys an asset identity in the attributes of a reference element so that an AMS can
validate the reference.
Validation means that the identified asset is known to the AMS, and that the intersection of the lifetimes of the
referencing and referenced assets is non-empty.
An AMS validated reference consists of a reference element as described in Section 5.4.2, having the attributes
providerID and assetID and also the attribute amsValidate with a value of "Y" (true), indicating that AMS validation
is requested. Such an element is used like any other element in a Metadata asset defined in an application
specification.
Example XML fragment showing AMS validated reference:

...
®
<vod:Terms format="SD" providerID="warnerbros.com"

assetID="TVNX745900000000102"
updateNum="1">
<adi:AssetLifetime
endDateTime="2005-04-15T00:00:00"/>
<vod:PreviewPeriod>0</vod:previewPeriod>
<vod:RentalPeriod>00:00:00</vod:rentalPeriod>
<vod:DistributorName>TVN</vod:DistributorName>
<vod:DistributorRoyaltyMiminum>0.00</vod: DistributorRoyaltyMiminum>
<vod:LanguageSet audio="en" subtitle="en"
<vod:ShowPart partNbr="1">
<vod:<ContentRef
assetID="TVNX745900000000101"
amsValidate="Y"/>
</vod:ShowPart>
</vod:LanguageSet>
</vod:terms>
...
An AMS, without application logic, can readily obtain all such references in an ADI2 document, regardless of the
structure of the assets in which they appear, e.g., by applying an XPath expression to return elements of interest
such as the following:
//node()[@amsValidate='Y']
5.5 Asset Updates
Assets are subject to only be replaced as a whole, i.e., all the fields of an asset will be replaced by the distribution of
a newer update of the asset message. As noted in Section 5.2.4, ReplaceMetadataAsset should in general be used for
error correction, and not as a general mechanism for providing new data to an application.
The common exception to this rule is to use ReplaceMetadataAsset to extend a "license window".
5.6 ADI Documents

There are several kinds of XML documents defined in this specification. These are named according to the
respective top-level elements:
ADI2: Asset Distribution Interface, version 2.
ACK: Delivery Acknowledgement.
XML documents MUST be encoded in UTF-8 as per the W3C XML 1.1 specification [XML]. If a document
encoding is not specified all XML documents are assumed to be UTF-8.
5.6.1 Means of Transmission
XML documents and content files MAY be transmitted by any means mutually agreed upon. These could include
FTP and email as well as satellite transmission.
®
5.6.2 Message Document Structure
Each kind of XML document begins with a number of common attributes and elements and MUST contain at a
minimum the Required fields as defined in Table 7 as follows:
Table 7 - Common Document Element and Attributes

ADI2 or Document root element REQUIRED
ACK or
other TBD
document
root elements
known to
AMS
sender The organization immediately Domain name of the sender, REQUIRED
responsible for sending the similar to a providerID; ASCII
document. X(1-25) but restricted to
ASCII X(1-20) unless
otherwise noted, lowercase.
docNumber A sender-unique number for ASCII X(1-25) REQUIRED
the document.
createDateTime DateTime value when the XML Date Time REQUIRED
document was created.
ackTo An optional URL to which an URI OPTIONAL
acknowledgement for this ADI
message may be posted.
relativePriority A hint as to the relative 1-10, Numeric OPTIONAL
priority of the delivery.
Contact A person at the sender who is REQUIRED
the contact for any problems
with the document
transmission.
firstName First name of contact. UNICODE OPTIONAL
lastName Last name of contact. UNICODE OPTIONAL
Department Department of sender company UNICODE OPTIONAL
to contact
phone Phone number of contact. ASCII REQUIRED
email Email address of contact. ASCII REQUIRED
Contact information is a component of every ADI 2.0 Message Document transmission and will represent a point of
contact for the entity originating the ADI 2.0 Message Document.
The value of these attributes and elements can be referenced in other human or computer queries and
acknowledgment messages after the original distribution message.
®
5.6.3 Asset Distribution Interface (ADI2)
An ADI2 document MUST begin with a document root element (e.g., ADI2 or ACK), followed by a Contact
element, with attributes specified above, and then contain one or more of the following elements specified in other
sections:
For ADI2:
OpenGroupAsset, DropGroupAsset, CloseGroupAsset, ReplaceGroupAsset

AddMetadataAsset, RemoveMetadataAsset, ReplaceMetadataAsset
AcceptContentAsset, DestroyContentAsset, ReplaceContentAsset
AssociateContent
For ACK:
DocReceived
For other document root elements:
To be determined in their own specifications
5.6.4 Delivery Acknowledgement (ACK)
The receiving application shall post a message to the URI delivered in the ADI 2.0 Message Document's ackTo field
indicating receipt and status of delivery. At a minimum an HTTP 1.1 [RFC 2616] POST message needs to be
supported for posting messages. The acknowledgement is by its nature asynchronous and will consist of an ADI 2.0
Message Document containing one or more acknowledgements for each asset delivery or content association.
Contact information on the returned ADI 2.0 Message Document is the recipient's contact information. It is intended
that the Delivery ACK be sent fairly soon after the document is initially processed. Information that needs more
processing should be done in some type of reconciliation mechanism.
The Delivery Acknowledgement (ACK) contains data values specific to its type and MUST contain at a minimum,
the Required fields as defined in Table 8.
Table 8 - Acknowledgement Element fields

DocReceived REQUIRED
docSender Of the received as received REQUIRED
document.
docNumber Of the received as received REQUIRED
document.
status The status of the See below REQUIRED
received
document being
acknowledged.
®

Response types One response REQUIRED to be
element for each in ACK document
ADI action for Content
Operation
Response types
only; OPTIONAL
for all other
Response types
depending on
agreements
Fields common to non
associate response elements
Asset must be equal to the
[ElementName] that
was transmitted
product The product, or ASCII X(1-32) REQUIRED
application for
the group, e.g.,
"VOD",
"Games"…
providerID Of the Asset common REQUIRED
assetID Of the Asset common REQUIRED
updateNum The updateNum ASCII Numeric REQUIRED
of the Asset
groupAsset ASCII (1-255) OPTIONAL
asset
reason Reason for ASCII (1-255) OPTIONAL
failure
Content Operation Additional
Response types: Fields for
AcceptContentAssetResp Content
DestroyContentAssetResp Operations
ReplaceContentAssetResp
metadataOnly ContentAsset String "Y" or "N" OPTIONAL
flag to allow for
Content
metadata to be
delivered
without content
fileSize Size of the Numeric (64 bits) OPTIONAL
content file in
bytes
fileName Name of the ASCII (1-32) OPTIONAL
content file Must be OS
independent
®

mD5Checksum Checksum of Hexadecimal(32) OPTIONAL
file received
Metadata Operation Additional
Response Types: Fields for
AddMetadataAssetResp Metadata
Operations
RemoveMetadataAssetRes
p
ReplaceMetadataAssetResp
Group Operations Additional
Response types: Fields for Group
OpenGroupAssetResp Operations
DropGroupAssetResp
CloseGroupAssetResp
ReplaceGroupAssetResp
No extension
fields for Group
Assets
*** The construction of AssociateContentResp is idiosyncratic and does not have the same common fields as the
other response types. A successful response message may only indicate that the AssociateContent message was
valid not that the actual association was done.***
AssociateContentResp
Asset must be equal to the
[Element
Name] that was
transmitted
effectiveDate common OPTIONAL
providerID Of the Asset common REQUIRED
assetID Of the Asset common REQUIRED
asset
reason Reason for ASCII (1-255) OPTIONAL
failure
®
Document State Values:
Table 9 - Document Status Values
Document Status Description

Successful The delivered document or operation was successfully received, including any content
files specified.
Failed The delivered document or operation was not successfully received.
5.7 Schema
An XML Schema is provided both as an inclusion and as companion document to functionally embody the
structures defined in this document.
Extension mechanisms exist ( e.g., W3C XML Schema :include, :redefine, :extension, :import…) to allow this
common ADI structure to be extended to support all of the asset definitions of the fields working group.
Schemas will be updated on an as needed basis to add new features, fix existing issues, etc. Schema changes shall
be made so as to minimally impact existing applications. Any breaking changes that need to be made to an ADI2
schema shall cause the schema version to be changed. Schema versioning will be done by changing the ADI2
namespace. The year, month part of the namespace will be changed to reflect the release date of the changed schema
and will serve as the schema version. No explicit version number will be put in the schema or its namespace.
Previous versions of the ADI2 core schemas shall remain valid when used in application schemas. Updating an
application schema to reflect core schema changes is optional.
5.7.1 Document Validation

XML schemas should be used to validate the correctness of ADI2, ACK documents and other TBD documents.
AMS implementations should validate documents against known schemas. At minimum this would be the ADI2
core schemas. AMS implementations may know about other schemas (e.g., VOD), but is not required. For qualified
elements defined in unknown schemas AMS can check them for well formed xml only.
AMS implementations may apply additional validation after schema validation has succeeded. For example: a
"gross" validation of content assets to validate transmission success using file size and checksum values; validating
asset lifetime windows in group context (see Section 2).
A document failing or passing AMS validation will cause AMS to attempt to send an appropriate ACK message to
the URL identified by the ackTo element in the request document.
AMS implementations are not required to apply application specific validation outside of schema validation to the
document.
Ordering of asset operations in an ADI2 document will not be significant for schema validation.
The schema validation step will not attempt to reconcile operations before validating succeeding operations (i.e.,
reference checking will not be done through xml schema - it will be a post schema validation step).
5.7.2 Schema Separation
The ADI 2.0 asset structure specification will define a messaging layer for communicating asset operations between
providers and consumers; and a data layer that defines the common asset structures needed to represent application
independent asset metadata.
®
• Allow the message layer to be versioned independently of the data layer.

• Separate AMS and application validation.
Applications will define XML schemas for application specific data types, using the core data schema for common
data types.
• Allow application development to occur independently of core specification and other applications.
• Allow extension of ADI by creating new applications and versioning existing ones without affecting the core
specification.
• Encourage independent trial application development.
• Encourage reuse of common data types and promotion of useful application data types to the core specification.
5.7.3 XML Namespaces
XML Namespaces (as defined in http://www.w3.org/TR/REC-xml-names/) should be used to separate the different
schema domains, to avoid element and attribute name collision and allow application development to occur
independently of the core specifications and other applications. The structure of ADI2 namespaces should follow a
common format. There are several formats that are currently in use. The recommended format is one that loosely
follows W3C guidelines (domain URL/year/application/subsystem). Proposed namespaces for the core
specifications: Multiple schema files may be used to define the elements in one namespace. For example the ADI2
core schema will consist of 2 schema files, one for the message elements (adi2msg.xsd) and one for the core
datatypes (adi2core.xsd). They will both share the same namespace. Note that namespace for the application will
define the ADI version that it is using.
ADI2 namespace: http://www.cablelabs.com/2006-05-05/ADI2
Sample application schema: http://www.cablelabs.com/2006-05-05/ADI2/Application/VOD
®
Appendix I ADI 1.1 Comparison (Informative)
This example is a free interpretation of an ADI 1.1 XML document mapped into an ADI 2.0 document. The VOD
2.0 specification is the governing specification with respect to the currently defined metadata fields; therefore, this
example uses commonly proposed snippets of possible ADI1.1 to ADI 2.0 comparisons and is intended to be
informative.
Note that the Package and its providerID/assetID do not exist in the ADI 2.0. The GroupAsset is not equated to a
package; the grouping entity is the VODRelease.
Single Asset ADI 1.1 to ADI 2.0 Example:
®
®
®
Appendix II AMS Re-Distribution (Informative)
II.1 Dispatching Model for an AMS
In an operational environment, Assets have to be dispatched to distinct physical locations and to varying
configurations of software and computers that collectively provide services to subscribers.
Suppose at one location (HE241), movies on demand are delivered to subscribers by an integrated VOD Application
Server that both interacts with the STB UI and streams the video to the plant. In another location, (HE237), there is
a "Navigator" application that that is responsible for interacting with the STB, and a VOD Server which plays out
the video and passes price and BillingID to the Billing System.
One AMS services several locations. The dispatch rules can be very simply represented in a table as follows:
Location Service Point Product Group Type Asset Type

HE241 VODIngest MOD Title ALL
HE237 NAVIGATOR MOD Title Title
HE237 NAVIGATOR MOD Title Movie
HE237 VODIngest MOD Title Movie
HE237 VODIngest MOD Title Video
®
Appendix III Derived Files (Informative)
There are several reasons why an MSO may process a content file received from a Provider, including
Pre–encryption, trick file generation, different encoding,
The result of such processing is a number of content files unknown to the Provider which have to be distributed
appropriately within the MSO's systems.
We refer to such files as "derived" files.
This appendix outlines how ADI2 constructs are used to distribute these files.
5.8 Provider's Content Asset
A Provider sends a content asset and the corresponding content file to an MSO:
<adi:AcceptContentAsset type="Video" product="VOD"

metaDataOnly="N"
fileSize="5616346216"
mD5CheckSum="bd11596299d5fe551e9f47e38dca5a70" /
contentURL="ftp://unam123@ftp.movies.com/etc/analyzethatcombo.mpg"
>
<vod:Video
assetID="TVNX74590000000010"
updateNum="1"
fileSize="5616346216"
encodingProfile="MPEG2SD"/>
<adi:AssetLifetime
endDateTime="2006-04-15T00:00:00"/>
<vod:EncryptionRequired>N</vod:EncryptionRequired>
<vod:BitRate>3750</vod:BitRate>
<vod:Description>MPEG SD for Partners</vod:Description>
<vod:StreamTimeTime>782416</vod:StreamTime>
<vod:AudioType languagecode="en" PID="0x1E2">Dolby Digital</vod:AudioType>
</vod:Video>
The Provider also sends an AssociateContent signal:
<adi:AssociateContent type="Video" Product="VOD"

groupProviderID="warnerbros.co"
groupAssetID="TVNX7459000000000001"
assetID="TVNX74590000000010"
/>
5.9 MSO-Produced Content Asset
An MSO generates a set of trick files for a particular content asset. One of them is for Fast Forward, 4X speed.
®
The MSO workflow generates a content asset, and delivers it to the same endpoints as the original CA:
<adi:AcceptContentAsset type="Video" product="VOD"

metaDataOnly="N"
fileName="analyzethatcomboTrick4.mpg"
fileSize="316456326"
mD5CheckSum="7e38dca5a551e9f470bd11596" /
contentURL="ftp://cmc428@ftp.cmc.mso.com/etc/analyzethatcomboTrick4.mpg"
>
<vod:VideoTrick
providerID="MSO.com"120
assetID="MSOT0000000081450037"
updateNum="1"
fileName="analyzethatcomboTrick4.mpg"
fileSize="316456326"
mD5CheckSum="7e38dca5a551e9f470bd11596" />
<adi:AssetLifetime
endDateTime="2006-04-15T00:00:00"/>
<vod:TrickMode>FF4X /vod:TrickMode>
<vod:Description>FF 4X Trick for analyzethat combo</vod:Description>
<vod:TargetServer serverType="MediaHawk" serverVendor= "Concurrent"/>
<vod:DerivedFrom>
<vod:ContentRef providerID="warnerbros.com"
assetID="TVNX74590000000010" />
</vod:DerivedFrom>
</vod:Video>
The DerivedFrom element provides the information to relate a derived file to its parent. Thus routing mechanisms
can transport the trick files according to the destination of the Provider's original CA.
If the Provider transmits a replacement content file for a particular content asset, the MSO's database can provide all
the MSO-produced derived content assets for that content asset. Thus a new set of derived files can be generated,
and delivered to the relevant end points using ReplaceContentAsset messages.
®
Appendix IV Revision History
The following ECNs were incorporated into version I02 of this specification:
ECN Author ECN Approval Problem Description

Date
ADI2.0-AS-N-06.0028-2 Neville Black 4/28/06 Derived Files
ADI2.0-AS-N-06.0030-3 Steve Young 4/28/06 Omnibus
The following ECNs were incorporated into version I03 of this specification:
ECN Author ECN Approval Problem Description

Date
ADI2.0-AS-N-06.0048-1 Jeffrey Sherwin 12/20/06 Unrestricted Filename Lengths
®

MD SP Adi2.0 As I03 070105

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

MD SP Adi2.0 As I03 070105

Încărcat de

Drepturi de autor:

Formate disponibile

Metadata 2.

ADI 2.0 Specification Asset Structure

Neither CableLabs nor any member company is responsible to any party

Document Status Sheet

Document Control Number: MD-SP-ADI2.0-AS-I03-070105

Document Title: ADI 2.0 Specification Asset Structure

Revision History: I01 - Issued 12/10/04

I02 - Issued 5/5/06

I03 - Issued 1/5/07

Date: January 5, 2007

Status: WIP Draft Issued Closed

Distribution Restrictions: Author Only CL/Member CL/ Member/ Public

Key to Document Status Codes:

Work in Progress An incomplete document, designed to guide discussion and generate

Draft A document in specification format considered largely complete, but

DOCSIS®, eDOCSIS™, M-CMTS™, PacketCable™, CableHome®, CableOffice™, OpenCable™,

4 ABBREVIATIONS AND ACRONYMS............................................................................................................6

APPENDIX II AMS RE-DISTRIBUTION (INFORMATIVE) ......................................................................28

APPENDIX III DERIVED FILES (INFORMATIVE)......................................................................................29

1.1 Introduction and Overview

1.2 Purpose of document

1.3 Organization of document

2.1 Normative References

2.2 Informative References

2.3 Reference Acquisition

• Worldwide Web Consortium, http://www.w3c.org

3 TERMS AND DEFINITIONS

This specification uses the following terms:

Alpha(4)Num(16) Format to indicate 4 initial alpha characters proceeding 16 numeric characters.

ASCII The subset of Unicode characters comprising U+0000 to U+007F, inclusive.

ASCII(1-255) 1 to 255 ASCII characters.

Delivery The transmission of data or content to a recipient.

Hexadecimal (32) 32 Hexadecimal characters.

Message Document An XML document containing one or more ADI messages.

UTF-8 (Unicode Transformation Format-8) is an octet (8-bit) lossless encoding of Unicode

X(1-25) Format to indicate should contain from 1-25 alphanumeric characters.

4 ABBREVIATIONS AND ACRONYMS

This specification uses the following abbreviations:

ADI Asset Distribution Interface

AMS Asset Management System

FTP File Transfer Protocol

HTTP HyperText Transfer Protocol

HTTPS HyperText Transfer Protocol Secure

MSO Multiple System Operator

PGM Pragmatic General Multicast

STB Set Top Box

URI Uniform Resource Identifier

UTF Unicode Transformational Format

W3C Worldwide Web Consortium

XML eXtensible Markup Language

ADI 2.0 uses the following basic concepts:

5.2 Asset structure

5.2.1 Common Asset Elements

Table 1 - Common Asset Element Fields

Element Attribute Definition Values Required

Element Attribute Definition Values Required

5.2.2 Asset Operations

5.2.3 Group Asset

the owner of metadata assets.

Table 2 - Group Asset Operation Types and Fields

Element Attribute Definition Values Required

The different envelope elements have the following semantics: