2.4 MPEG-7 Description Definition Language

 < Day Day Up > 



2.4 MPEG-7 Description Definition Language

The MPEG-7 DDL provides the solid descriptive foundation by which users can create their own description schemes and descriptors, providing a means for representing the conceptual model. It defines the syntactic rules to express and combine description schemes and descriptors and, thus, for writing MPEG-7 documents.

The DDL is based on the XML Schema recommendations published by W3C in May 2001 (see http://www.w3.org/XML/Schema). The complete DDL may be obtained from http://m7itb.nist.gov/M7Validation.html. In the following, we will concentrate on the content descriptive parts of the descriptions and provide a step-by-step methodology for content description in MPEG-7.

Note 

The DDL and MPEG-7 examples in this book use a different typesetting to be clearly identified, as shown in the following example:

 <complexType name="VideoType">   <sequence>     <element name="VideoTitle" type="string"/>   </sequence>   <attribute name="use" type="string" default="athome"/> </complexType> 

MPEG-7 example:

 <Video attribute="athome"/>   <VideoTitle>Pisa's leaning tower</VideoTitle> </Video> 

2.4.1 XML Schema: Overview

The purpose of a schema is to define a class of XML documents by specifying particular constructs that constrain the structure and content of the documents. Possible constraints include elements and their content, attributes and their values, cardinalities, and datatypes. XML Schema provides a superset of the capabilities of DTDs (document type definitions).

However, because XML Schema was not designed specifically for AV content, certain MPEG-7-specific extensions are added to XML Schema. As a consequence, the DDL can be broken down into the following logical normative components:

  • XML Schema structural components,

  • XML Schema datatype components, and

  • MPEG-7 extensions to the XML Schema.

Here we give a brief overview of XML Schema elements that are of importance for using MPEG-7 and MPEG-21 (see Chapter 3). More details and up-to-date tutorials may be obtained from the W3C XML Schema homepage at http://www.w3.org/XML/Schema.

2.4.2 XML Schema: Structures

The XML Schema: Structures (part 1 of the two-part XML Schema specification) provides facilities for describing the structure and constraining the content of XML 1.0 documents. A parser can then use them during the validation process. For instance, what elements may occur and how often, what attribute belongs to which elements, and so forth are specified.

XML Schema provides the means for defining the structure of XML documents. XML documents described by a particular schema are called instance documents and they are said to be schema valid if they comply with all constraints specified by the schema document. XML Schema includes the following main features:

  • Simple and complex data types,

  • Type derivation and inheritance,

  • Element occurrence constraints, and

  • Namespace-aware element and attribute declarations.

By using these features, it is now possible to define and enforce concise and strict rules regarding the contents of elements and attributes. For instance, one can now declare new data types or reuse and derive from existing data types.

Similar to instance documents, every schema document consists of a single root element. It includes declarations for all elements and attributes that are allowed to occur in a valid instance document.

2.4.3 Element Declaration

XML documents basically comprise a number of nested elements. Therefore, the element is one of the most important declarations in a typical schema document. The following example shows a simple schema:

 <?xml version="1.0" encoding="ISO-8859-1?"> <schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">     <element name="Video" type="string"/> </schema> 

This sample schema declares one global element, namely "Video." A global element is defined as an immediate child element of the schema element, and only such elements are allowed to appear as root elements of an instance document.

2.4.4 Attribute Declaration

To add useful information to an element, it is possible to attach attributes to it. For instance, the Video element might benefit from having an additional language attribute called "lang," whose purpose is to specify the video's language. Such a declaration might look like the following:

 <element name="Video">   <complexType>     <simpleContent>       <extension base="string">         <attribute name="lang" type="language" use             ="optional"/>       </extension>     </simpleContent>   </complexType> </element> 

2.4.5 XML Schema-Type Definitions

XML Schema introduces types as a new concept within XML. It is now possible to type element declarations, which was not feasible with DTDs. This feature also makes schema documents more powerful and better suited to the task of storing instance documents into a database. Type definitions define internal schema components, which can be used in other schema components such as element or attribute declarations or other type definitions. There are two kinds of type definition components: simple types and complex types.

Simple types are used for elements that can only contain text, meaning they are not allowed to include nested elements. Attributes must always be declared with simple types, as they cannot be nested or contain subelements. Simple types can be divided into three categories: atomar or built-in types, list types, and union types, the latter two being a feature particular to XML. Atomar types are, in general, types that can be found in programming languages or database management systems, such as String or Boolean. List types separate their entries via white spaces. Union types allow a type to draw from different type spaces. For instance, a list of integer values can be defined as follows:

 <simpleType name="integerVector">     <list itemType="integer"/> </simpleType> 

It is also possible to control the range of values a simple type may have through a concept called facets. For instance, a character data type might have a maxLength facet, restricting the maximum length of a string. The following example illustrates this:

 <simpleType name="exampleString">   <restriction base="string">     <maxLength value="40"/>   </restriction> </simpleType> 

This new simple type is derived from the built-in string data type, but must not contain more than 40 characters.

Complex types are used for elements that may contain subelements and also have attributes. If a type declaration is embedded within an element declaration, the type is called an anonymous type instead of a named type. Named types are needed if it is necessary to share data types among multiple different elements. In the last example of the previous section, element Video has an anonymous complex type.

Complex types are created either by deriving by extension or by restriction. Deriving by extension means that the new derived type inherits all declarations of the super type. Complex types derived by restriction are a bit more complicated, as parts of the parent declaration are omitted, constraining the parent type. To tell an instance document that a derived type should be used instead of the type expected, an xsi:type attribute must be added to the respective elements.

2.4.6 Types of Element Content

There are four possible types of element content available:

  • Empty,

  • Simple content,

  • Mixed content, and

  • Any type.

Empty elements are the most restrictive form of element content, as these elements cannot contain anything. They provide information either through attributes or simply because of their position relative to other elements.

Simple content corresponds to the definition of simple types as already discussed above, whereas mixed content is basically related to mixed content elements, meaning that both character data and other elements may occur within the element's body. Include the mixed attribute to the complexType element to specify such content. The least restrictive form of element content allows including any type of content at a particular location. This can be done by using either the any element or the anyAttribute element.

2.4.7 Occurrence Constraints

A very useful feature of XML Schema is the ability to constrain the number of times an element is allowed to occur at a particular location within a document. This can be done by adding the minOccurs and maxOccurs attributes to the element. The default value for both attributes is set to 1.

2.4.8 Element Placement

There are three ways of controlling the placement of elements with XML Schema. The sequence element specifies that all elements must appear in exactly the same order as within the sequence. The choice element supports the requirement that only one element from a list of alternatives should occur. The order is of no importance here. Finally, the all element tells the schema processor that each of the elements contained in the list must appear in the instance document, but that they may do so in an arbitrary order.

2.4.9 XML Schema: Datatypes

The XML Schema: Datatypes (part 2 of the two-part XML Schema specification) proposes facilities for defining datatypes to be used to constrain the datatypes of elements and attributes within XML Schemas. It provides a higher degree of type checking than is available within XML 1.0 DTDs.

It provides

  • A set of built-in primitive datatypes,

  • A set of built-in derived datatypes, and

  • Mechanisms by which users can define their own derived datatypes.

A derived datatype can be defined from a primitive datatype or another derived datatype by adding constraining facets. Precise details of the built-in datatypes and derivation mechanisms can be found in the DDL Specification, ISO-IEC 15938-2.

2.4.10 MPEG-7 Extensions to XML Schema

The following features need to be added to the XML Schema language specification to satisfy MPEG-7 specific requirements:

  • Array and matrix datatypes, both fixed size and parameterized size;

  • Built-in primitive time datatypes: basicTimePoint and basicDuration.

MPEG-7-specific parsers have been developed by adding validation of these additional constructs to standard XML Schema parsers. See http://m7itb.nist.gov/M7Validation.html for an overview.

2.4.11 MPEG-7 Headers: Namespaces

The description examples specified in this book assume that a schema wrapper is provided that identifies the XML Schema namespace (XML Schema) and MPEG-7 namespace:

 <schema xmlns="http://www.w3.org/2001/XMLSchema"   xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001"   targetNamespace="urn:mpeg:mpeg7:schema:2001"   elementFormDefault="qualified" attributeFormDefault="unqualified"> 

The following tag is used to close the schema:

 </schema> 

2.4.12 MPEG-7 Headers: Documents

All MPEG-7 documents should have the following header information:

 <?xml version="1.0" encoding="iso-8859-1?"> <Mpeg7 xmlns="urn:mpeg:mpeg7:schema:2001"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-        instance"     xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001"     xmlns:xml="http://www.w3.org/XML/1998/namespace"     xsi:schemaLocation="urn:mpeg:mpeg7:schema:2001 Mpeg7-2001.xsd"> <! - Your MPEG-7 content - > </Mpeg7> 

You may use the online validator at http://m7itb.nist.gov/M7Validation. html to check the comformance of your MPEG-7 document to the DDL.

2.4.13 Illustrative Example of the DDL Usage

The structural elements of XML Schema are extensively used in an MPEG-7 definition. Let us consider the very important definition of time (e.g., how to specify a time point in a video or the time duration of a video segment) as an illustration to the use of these elements in MPEG-7.

The time description represents the real world time (Time datatype) as well as the time as used in the AV data (mediaTime datatype). In both cases, time instances as well as time intervals can be described.

Exhibit 2.6 illustrates the simplest way to specify a temporal instant and a temporal interval. A time instant, t1, can be defined by a lexical representation using the TimePoint. An interval, [t1, t2], can be defined by its starting point, t1, (using the TimePoint) and a duration, t2 - t1.

Exhibit 2.6: Overview of the time entity.

start example

end example

Derived from the schema in Exhibit 2.6, the following Time datatype: TimeType is expressed in DDL:

 <! - Definition of Time datatype - > <complexType name="TimeType">   <sequence>     <choice>       <element name="TimePoint" type="mpeg7:           TimePointType"/>       <element name="RelTimePoint" type="mpeg7:           RelTimePointType"/>       <element name="RelIncrTimePoint" type="mpeg7:           RelIncrTimePointType"/>     </choice>     <choice minOccurs="0" >       <element name="Duration" type="mpeg7:           durationType"/>       <element name="IncrDuration" type="mpeg7:           IncrDurationType"/>     </choice>   </sequence> </complexType> 

For the specification of time intervals in the Time datatype, a complex type is used that is composed of two elements: the (start) time point and the duration. If only a time point is specified, the duration can be omitted, which is expressed by a sequence group element indicating that the start time must be specified in the sequence before the duration.

For the specification of the start time point, three alternatives may be used (specified by the choice element): TimePoint specifying a concrete time point; RelTimePoint, where the start time is defined as a temporal offset with respect to a reference point; and finally RelIncrTimePoint, where the start time is also defined as a temporal offset to a reference, but this time with respect to time units. We will show how TimePoint is defined; the two latter are not discussed in detail here.

The duration element is optional, which is indicated by minOccurs = "0." Two alternatives for expressing the duration are available. Duration specifies the duration of a time period according to days and daytime and is detailed later, and IncrDurationType defines the duation of a time period with respect to time units.

The TimePointType specifies a time point according to the Gregorian dates and day time and the time zone.

 <! - Definition of TimePoint datatype - > <simpleType name="TimePointType">   <restriction base="mpeg7:basicTimePointType">     <pattern value="(\-?\d+(\-\d{2}(\-\d{2})?)?)?            (T\d{2}(:\d{2}(:\d{2}            (:\d+)?)?)?)?(F\d+)?(\-|\+\d{2}:\d{2})?"/>   </restriction> </simpleType> 

The TimePointType is a simple type with no child elements. It is a restriction of another simple type. A restriction narrows the ranges or reduces alternatives of elements or attributes. Here we narrow the range of a built-in datatype string, from which basicTimePointType is derived, by the use of the pattern element. The complex looking pattern tells us that the format of the TimePointType is YYYY-MM-DDThh:mm:ss:nnn-FNNN±hh:mm.

For instance, a time instant of December 17, 2002, at 13 hours, 20 minutes, 1 second, and 235 milliseconds would be expressed using TimePointType by 2002-12-17T13:20:01:235F1000. According to the number of decimal digits used, the number of fractions of one second are 1000, as specified in the timePointType.

The durationType specifies the duration of a time period according to days and daytime. Fractions of a second are specified according to the TimePointType. The definition of the durationType uses again a simple type.

 <! - Definition of duration datatype - > <simpleType name="durationType">   <restriction base="mpeg7:basicDurationType">     <pattern value="\-       ?P(\d+D)?(T(\d+H)?(\d+M)?(\d+S)?(\d+N)?)?(           \d+F)?((\-     |\+)\d{2}:\d{2}Z)?"/>   </restriction> </simpleType> 

EXAMPLE: The following example describes the time of an event that started on the October 16, 2002, at 17:00 in a country whose time zone is 1 hour ahead of GMT (or Universal time), such as Austria, and has a duration of 10 days:

 <Time>   <TimePoint>2002-10-16T17:00+01:00</TimePoint>   <Duration>P10D</Duration> </Time> 



 < Day Day Up > 



Distributed Multimedia Database Technologies Supported by MPEG-7 and MPEG-21
Distributed Multimedia Database Technologies Supported by MPEG-7 and MPEG-21
ISBN: 0849318548
EAN: 2147483647
Year: 2003
Pages: 77
Authors: Harald Kosch

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net