[cvs-annodex] commit (/annodex):
+standards/draft-pfeiffer-v2-update.xml
silvia
nobody at lists.annodex.net
Tue Feb 15 10:51:27 EST 2005
Update of /annodex (new revision 910)
Added files:
standards/draft-pfeiffer-v2-update.xml
Log Message:
Instead of branching the CMML I-D I'm working on a copy of the CMML v3 draft and reducing it back to v2.
Beat me up, but I found it too hard to make a branch.
Added: standards/draft-pfeiffer-v2-update.xml
===================================================================
--- standards/draft-pfeiffer-v2-update.xml 2005-02-14 23:46:26 UTC (rev 909)
+++ standards/draft-pfeiffer-v2-update.xml 2005-02-14 23:51:24 UTC (rev 910)
@@ -0,0 +1,2705 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
+<?rfc toc="yes" ?>
+<rfc ipr="full2026">
+ <front>
+ <title abbrev="CMML">The Continuous Media Markup Language (CMML), Version 3.0</title>
+
+ <author initials="S.P." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4180</phone>
+ <email>Silvia.Pfeiffer at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+
+ <author initials="C.D." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4222</phone>
+ <email>Conrad.Parker at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+
+ <author initials="A.T." surname="Pang" fullname="Andre T. Pang">
+ <organization abbrev="CSIRO">Commonwealth Scientific and
+ Industrial Research Organisation CSIRO,
+ Australia</organization>
+ <address>
+ <postal>
+ <street>PO Box 76</street>
+ <city>Epping</city>
+ <region>NSW</region>
+ <code>1710</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+61 2 9372 4222</phone>
+ <email>Andre.Pang at csiro.au</email>
+ <uri>http://www.ict.csiro.au/</uri>
+ </address>
+ </author>
+
+ <date month="December" year="2004"/>
+
+ <abstract>
+ <t>This specification defines the Continuous Media Markup
+ Language (CMML), version 3.0, an <xref
+ target="XML">XML-based</xref> markup language for
+ time-continuous data. It is a sister document to the
+ specification of the <xref target="ANX">Annodex</xref>
+ annotation, indexing and hyperlinking format for time-continuous
+ data. Its tags provide for the creation of structured and
+ unstructured annotations as well as hyperlinks and addressable
+ named anchor points for clips of time-continuous data. As well
+ as enabling the creation and storage of such meta data in XML
+ files, the CMML is an authoring language for <xref
+ target="ANX">Annodex</xref> streams through its import tags. The
+ tag names in use in CMML are similar to the ones in <xref
+ target="XHTML">XHTML</xref>.
+ </t>
+
+ <t>At this point in time, the right to produce derivative works
+ is not granted to the IETF as the authors are uncertain about
+ the necessity to create a working group. The specification is
+ not encumbered by patents. The Annodex format is protected by a
+ trade mark to prevent the use of the term "Annodex" for any
+ related but non-conformant and therefore non-interoperable
+ technology. Conformant technology is encouraged to use the term
+ "Annodex" when refering to the file format.
+ </t>
+
+ <t>Notice the change to CMML 3.0 from CMML 2.0, which extends
+ the CMML with tags that allow stylesheet specifications for the
+ presentation of the CMML tags, adds the link tag, the title and
+ class attributes, and renames "timebase" to "basetime" as that
+ is the more accurate term used in the industry.
+ </t>
+
+ </abstract>
+ </front>
+
+ <middle>
+
+ <!--**************-->
+ <!-- ARCHITECTURE -->
+ <!--**************-->
+ <section title="The architecture of a Continuous Media Web">
+
+ <t>As with Webpages, Annodex format bitstreams first have to
+ be authored and then published on a server. Authoring includes
+ the creation of the media bitstream plus the creation of
+ annotations (i.e. textual data descriptions), indexes
+ (i.e. anchor points) and hyperlinks (i.e. <xref
+ target="URI">URIs</xref>) for clips of the media
+ data. Annotations, indexes and hyperlinks are created in
+ "head" and "clip" tags conformant to the CMML specification, and
+ interleaved into the media document to create
+ Annodex format bitstreams in a time-synchronous
+ fashion. This procedure can be performed both on files and live
+ streams. The collection of Annodex format bitstreams on the
+ Internet is called the Continuous Media Web as it builds a Web
+ of time-continuous resources.
+ </t>
+
+ <t>To access the Continuous Media Web, a client such as a
+ conformant Web browser is required. A client can link to an
+ Annodex bitstream via a URI. A URI can point to a temporal
+ offset in the Annodex bitstream using <xref
+ target="timedURI">URI time interval specifierss</xref> or to
+ a named offset by using the id tag of a clip element as a URI
+ fragment identifier. In this way, direct access to points of
+ interest in the media document is enabled. While playing back
+ Annodex format bitstreams, a user is being offered
+ hyperlinks (URIs) to other Web resources which
+ are related to the currently displayed media content.
+ </t>
+
+ <t>A client may be a special player or a browser plugin. This
+ application must split an Annodex format bitstream into its
+ constituent time-continuous data streams and the annotation
+ bitstream consisting of "head" and "clip" tags. A
+ decoder is required to display the encapsulated media document
+ after decoding it with the appropriate media decoder. While
+ playing back the media document, the application displays the
+ hyperlinks and the annotations for the active clips.
+ </t>
+
+ <t>Search engines can include published Annodex format files
+ into their search repertoire by finding annotations in the
+ clip tags in a standard way independent of the encoding and
+ packetising format of the annodexed time-continuous data
+ streams. This allows any media
+ format to be spidered. In addition, the protocol should allow the
+ downloading of only the CMML mark-up from a published Annodex
+ format file in order to discourage spiders from creating extensive
+ network loads, as they do not need to download the media
+ bitstream to gain the necessary information. It also reduces the
+ size of search archives, even for large amounts of published
+ Annodex format files, because a CMML file contains all
+ searchable annotations for the clips of its
+ Annodex format file.
+ </t>
+
+ </section>
+
+
+ <!--**************-->
+ <!-- INTRODUCTION -->
+ <!--**************-->
+ <section title="Introduction">
+
+ <t>Please note that this document assumes that the reader has a
+ fluent working knowledge of <xref target="XML">Extensible Markup
+ Language (XML)</xref>, <xref target="HTML">Hypertext Markup
+ Language (HTML)</xref>, <xref target="XHTML">XHTML</xref>,
+ <xref target="CSS">Cascading Style Sheets (CSS)</xref> and
+ the World Wide Web. Basic knowledge about the <xref
+ target="ANX">Annodex</xref> format is also assumed.
+ </t>
+
+ <t>Time-continuous data in the Annodex format contains XML-based
+ annotations and hyperlinking information that enables it to be
+ browsed by client applications, and crawled and indexed by
+ search engines. The Continuous Media Markup Language CMML is a
+ simple markup language for authoring and storing the XML data to
+ be multiplexed with the time-continuous data given in binary
+ bitstreams. This process eventually creates Annodex format
+ bitstreams.
+ </t>
+
+ <t>The format of the CMML derives much from XHTML. Yet, instead
+ of enabling the annotation of textual documents, it enables
+ creation of mark-up for time-continuous documents. CMML has a much
+ stricter separation of structure and presentation information than
+ HTML or XHTML. CMML's tags only hold structural and semantic tags,
+ while the presentation of these tags in a user interface is fully
+ controlled by style sheets.
+ </t>
+
+ <t>The CMML can describe one or several time-continuous data
+ bitstreams. It is used to create all the tags required for
+ authoring the annotation information for the Annodex format. It
+ therefore contains the same tags as the annotation bitstream in
+ Annodex format, which are the "head" and the "clip" tags. In
+ addition, it may contain a stream tag, which is required for
+ identifying and synchronising one or several input bitstreams
+ that will be multiplexed together with the annotations for the
+ creation of one coherent Annodex format bitstream.
+ </t>
+
+ <t>The following picture illustrates the multiplexing activity
+ schematically; in reality, the stream tag is not preserved in its
+ original form and some attributes are also made irrelevant during
+ multiplexing. Details of how CMML markup is encoded in an
+ Annodex bitstream are given later in this document.
+ </t>
+ <figure>
+ <artwork><![CDATA[
+ ----------
+ |stream | CMML
+ ---------- instance
+ | head | document
+ ----------
+ | clip_1 | ----------------------------------------------------
+ ---------- | data bitstream in packets |
+ | ... | ----------------------------------------------------
+ ---------- |
+ | clip_n | |
+ ---------- |
+ | |
+ ------->-<-------
+ | Multiplexing
+ |
+ v
+ ----------------------------------------------------------------------
+ |stream|head|clip_1| data packets |clip_2| data packets ...
+ ----------------------------------------------------------------------
+ ]]></artwork>
+ </figure>
+
+ <t>The file extension of CMML files is ".cmml". This document
+ also applies for registration of the mime-type "text/cmml" for
+ CMML files with IANA. In the meantime, "text/x-cmml" will be
+ used.
+ </t>
+
+ <t>The CMML is technically fully specified through its DTD as
+ given in the Appendix. The semantic meaning of each of the tags,
+ their content and their attributes is specified in the following
+ sections. The Appendix also contains an example of a CMML
+ (instance) document.
+ </t>
+
+ </section>
+
+ <!--************-->
+ <!-- CMML types -->
+ <!--************-->
+ <section title="The CMML data types">
+
+ <t>At the beginning of the CMML DTD, several parameter entities
+ are defined that are used throughout the DTD as data types. This
+ section gives a brief overview of them and refers to the
+ relevant standards in which they are defined.
+ </t>
+
+ <section title="ContentType">
+ <t>A "ContentType" specifies the media type and subtype of a
+ document as defined in <xref target="ContentType">RFC
+ 2045</xref>. It is used to specify the type of content that
+ one input time-continuous bitstream contains. Examples are
+ "application/annodex", "audio/x-speex", "video/x-theora", or
+ "video/mpeg".
+ </t>
+ </section>
+
+ <section title="LinkTypes">
+ <t>"LinkTypes" specifies a space-separated list of the types of
+ relationships a linked, i.e. related, document has to the current
+ one. As in XHTML, user agents, search engines, etc. may interpret
+ these link types in a variety of ways. For example, user agents
+ may provide access to linked documents through a navigation bar.
+ Authors may use the following recognized link types which are a
+ subset of the ones used for XHTML/HTML:
+ <list style="symbols">
+ <t>alternate: Designates substitute versions for the document
+ in which the link occurs. When used together with the media
+ attribute, it implies a version designed for a different
+ medium (or media).
+ </t>
+ <t>stylesheet: Refers to an external style sheet.
+ </t>
+ <t>start: Refers to the first document in a collection of
+ documents. This link type tells search engines which document
+ is considered by the author to be the starting point of the
+ collection.
+ </t>
+ <t>next: Refers to the next document in a linear sequence of
+ documents. User agents may choose to pre-load the "next"
+ document, to reduce the perceived load time.
+ </t>
+ <t>prev: Refers to the previous document in an ordered series of
+ documents.
+ </t>
+ <t>contents: Refers to a document serving as a table of contents.
+ Although this may seem strange in a CMML file, it makes sense
+ in an Annodex file and may simply refer back to the CMML file
+ or to a HTML page that provides similar information.
+ </t>
+ <t>index: Refers to a document providing an index for the current
+ document.
+ </t>
+ <t>glossary: Refers to a document providing a glossary of terms
+ that pertain to the current document.
+ </t>
+ <t>copyright: Refers to a copyright statement for the current
+ document. While this could also be given in the meta tags,
+ this could refer to a formatted, legal document.
+ </t>
+ <t>chapter: Refers to a document serving as a chapter in a
+ collection of documents.
+ </t>
+ <t>section: Refers to a document serving as a section in a
+ collection of documents.
+ </t>
+ <t>subsection: Refers to a document serving as a subsection in a
+ collection of documents.
+ </t>
+ <t>appendix: Refers to a document serving as an appendix in a
+ collection of documents.
+ </t>
+ <t>help: Refers to a document offering help (more information,
+ links to other sources information, etc.)
+ </t>
+ <t>bookmark: Refers to a bookmark. A bookmark is a link to a key
+ entry point within an extended document. The title attribute may
+ be used, for example, to label the bookmark. Note that several
+ bookmarks may be defined in each document.
+ </t>
+ </list>
+ </t>
+ </section>
+
+<!-- IS DISCOURAGED IN XHTML, SO LET'S NOT START BAD STYLE
+ <section title="StyleProperties">
+ <t>A "StyleProperties" specifies style properties to be used for
+ this element. This is used for the style attribute, which
+ specifieds style information for the current element.
+ In XHMTL the use of the style attribute is strongly discouraged
+ in favor of the style element and external style sheets. Small
+ devices don't generally support these in-line styles.
+ </t>
+ </section>
+-->
+
+ <section title="MediaDesc">
+ <t>A "MediaDesc" describes one or several types of devices for
+ which the given style is appropriate. Which devices are supported
+ will need to be specified in a separate style sheet specification.
+ The following set of device types, adapted from XHTML/HTML
+ in CSS1, are currently recommended:
+ <list style="symbols">
+ <t>all: suitable for all devices.
+ </t>
+ <t>aural: suitable for speech synthesizers.
+ </t>
+ <t>braille: intended for braille tactile feedback devices.
+ </t>
+ <t>embossed: intended for paged braille printers.
+ </t>
+ <t>handheld: intended for handheld devices (characterized
+ by a small, monochrome or colour display and limited bandwidth).
+ </t>
+ <t>print: intended for paged output to a printer or print
+ preview on a screen.
+ </t>
+ <t>projection: intended for projected presentations (projectors
+ or print to transparencies).
+ </t>
+ <t>screen: intended for non-paged, colour computer screens.
+ </t>
+ <t>tty: intended for fixed-pitch character grid displays (such
+ as the teletypes or terminals).
+ </t>
+ <t>tv: for television-type devices with low resolution and
+ limited scrollability.
+ </t>
+ </list>
+ </t>
+ </section>
+
+ <section title="Text">
+ <t>A "Text" describes a short, free form text being used for
+ the "title" attribute.
+ </t>
+ </section>
+
+ <section title="URIs">
+ <t>A "URI" is a character string that conforms to the
+ specification of the Uniform Resource Identifier as defined in
+ <xref target="URI">RFC 2396</xref>. A URI generally points to
+ a Web resource. The <xref target="timedURI">URI time interval
+ specification</xref> is supported for CMML and Annodex
+ files. Also, direct addressing of clips as specified in the
+ MIME type application part of this document is supported for
+ CMML and Anndex files.
+ </t>
+ </section>
+
+ <section title="LanguageCode">
+ <t>The "LanguageCode" defines a collection of constant strings
+ that each identify a specific language as defined in <xref
+ target="LANG">RFC 1766</xref>. Examples are: en-au, de, x-klingon.
+ Language codes are used to provide internationalisation support.
+ </t>
+ </section>
+
+ <section title="Internationalisation support">
+ <t>To provide international language support, the i18n entity
+ draws together a language given by a "LanguageCode" with the
+ directionality of that language in "dir" given either as ltr
+ (left-to-right) or rtl (right-to-left). "ltr" is the default.
+ </t>
+ </section>
+
+ <section title="Time specifications">
+ <t>There are three different time specifications in use in
+ CMML: "Timestamp", "Playbacktime" and "UTCtime".
+ </t>
+
+ <t>A "Timestamp" is generally a name-value pair which defines
+ a time point. The time point value is interpreted according to
+ the time scheme given in the name. If the name is ommitted, it
+ defaults to "npt:". At least the following time specifications
+ are defined:
+ <list style="symbols">
+
+ <t>"npt" is "normal playback time" as used in the <xref
+ target="RTSP">RTSP standard</xref>.
+ </t>
+
+ <t>"smpte" are several frame-based time labels as defined
+ by the <xref target="SMPTE">Society of Motion Pictures and
+ Television Engineers</xref>. As fractional frames are
+ meaningless for video and ambiguous for audio in the
+ drop-frame situations, they are not used. The drop-frame
+ algorithms for calculating the exact times can be found in
+ the mentioned SMPTE standard.
+ </t>
+
+ <t>"utc" is the "universal time code" as specified in the
+ <xref target="ISO8601">ISO 8601 standard</xref>.
+ </t>
+
+ </list>
+ </t>
+
+ <t>The formal specifications for the time schemes are:
+ <list style="empty">
+
+ <t>"npt:" NPT time with a second or subsecond basis</t>
+ <t>Specification as BNF:</t>
+ <artwork><![CDATA[
+npt-spec = "npt:" npt-time
+npt-time = npt-sec | npt-hhmmss
+npt-sec = 1*DIGIT [ "." *DIGIT ]
+npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ]
+npt-hh = 1*DIGIT
+npt-mm = 1*2DIGIT
+npt-ss = 1*2DIGIT
+ ]]></artwork>
+
+ <t> "smpte-24:" SMPTE time with a 24 fps basis</t>
+ <t> "smpte-24-drop:" SMPTE time with a 24/1.001 fps basis</t>
+ <t> "smpte-25:" SMPTE time with a 25 fps basis</t>
+ <t> "smpte-30:" SMPTE time with a 30 fps basis</t>
+ <t> "smpte-30-drop:" SMPTE time with a 30/1.001 fps basis</t>
+ <t> "smpte-50:" SMPTE time with a 50 fps basis</t>
+ <t> "smpte-60:" SMPTE time with a 60 fps basis</t>
+ <t> "smpte-60-drop:" SMPTE time with a 60/1.001 fps basis</t>
+ <t>Specification as BNF:</t>
+ <artwork><![CDATA[
+smpte-spec = smpte-type ":" smpte-time
+smpte-type = "smpte-24" | "smpte-24-drop" | "smpte-25" |
+ "smpte-30" | "smpte-30-drop" | "smpte-50" |
+ "smpte-60" | "smpte-60-drop"
+smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
+ ]]></artwork>
+
+ <t>"clock:" UTC time with a second or subsecond basis</t>
+ <t>Specification as BNF:</t>
+ <artwork><![CDATA[
+utc-spec = "clock:" utc-time
+utc-time = utc-date "T" utc-hhmmss "Z"
+utc-date = 8DIGIT
+utc-hhmmss = 6DIGIT [ "." *DIGIT ]
+ ]]></artwork>
+
+ </list>
+ </t>
+
+ <t>The "Playbacktime" entity is a data type that just
+ specifies a SMPTE or a NPT time. It is therefore equal to the
+ Timestamp entity without the UTC specification.
+ </t>
+
+ <t>The "UTCtime" entity is a data type that just specifies a
+ UTC time without an identifier. UTC time is specified as in
+ the Timestamp entity, but without the "clock:" identifier.
+ </t>
+
+ </section>
+
+ <section title="Core Attributes">
+ <t>To cluster together the attributes that are common to
+ most displayable elements, the "attrs" entity draws them together.
+ As "i18n" is already a cluster, a "coreattrs" entity is defined,
+ which groups together the other commonly used attributes for
+ displayable elements, namely the unique identifier given in "id",
+ the "class" attribute which provides a space-separated list of
+ style sheet classes that the element belongs to, and the "title"
+ attribute, which provides a short tooltip-like description
+ for an element.
+ </t>
+ </section>
+
+ </section>
+
+
+ <!--**************-->
+ <!-- Root element -->
+ <!--**************-->
+ <section title="The preamble and the 'cmml' root element">
+
+ <t>A CMML file is an XML instance document of the CMML DTD. An
+ example is given in the Appendix. It starts with the usual xml
+ directive and the DTD specification (see
+ http://www.w3.org/TR/REC-xml#sec-prolog-dtd). The following is
+ an example preamble:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<!DOCTYPE cmml SYSTEM "cmml.dtd">
+ ]]></artwork>
+ </figure>
+
+ <t>The attribute "standalone" is set to "yes" when the only DTD
+ that is used for the instance document is cmml.dtd. The encoding
+ format specifies the character encoding that is used for the
+ values of the attributes and elements of the CMML file. E.g. for
+ languages that are non-latin based, such as most Arab and Asian
+ languages, a simple character encoding like US-ASCII does not
+ cover all the characters. The default "UTF-8" charset can
+ accommodate for any and all.
+ </t>
+
+ <t>After the preamble, the CMML tag follows. A CMML file has a
+ "cmml" tag as the root element. It embraces all the other tags.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT cmml (stream?, head, clip*)>
+<!ATTLIST cmml
+ %i18n;
+ id ID #IMPLIED
+ xmlns %URI; #FIXED 'http://www.annodex.net/cmml'
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The "cmml" tag encloses at most one "stream" element, exactly
+ one "head" element, and as many "clip" elements as the document
+ author requires. A "clip" element describes a section of the to
+ be created Annodex bitstream. The Annodex bistream is created by
+ multiplexing the bitstreams given in the "src" attributes of the
+ "import" tags of the "stream" element together with the CMML
+ annotations in a time-synchronous manner, as specified in the
+ <xref target="ANX">Annodex format</xref>.
+ </t>
+
+ <t>Attributes of the "cmml" element are the usual xml root tag
+ attributes: the internationalisation attributes "lang" and
+ "dir", an identifier "id" and a fixed namespace "xmlns".
+ </t>
+
+ <t>The internationalisation attributes specify the default
+ language (language and directionality) of the complete CMML
+ document. If not given, the language default adheres to the same
+ rules as HTML, where the setting of the HTTP "Content-Language"
+ header may specify the default language of a HTML document
+ received over HTTP, or ultimately the user agent defaults and
+ user preferences set the language. (see
+ http://www.w3.org/TR/REC-html40/struct/dirlang.html)
+ </t>
+
+ </section>
+
+
+ <!--****************-->
+ <!-- Stream element -->
+ <!--****************-->
+ <section title="The cmml 'stream' tag">
+
+ <t>The "stream" element contains information that is used for
+ authoring <xref target="ANX">Annodex format</xref> bitstreams
+ from existing time-continuous data. It thus describes the input
+ time-continuous bitstreams that are to be multiplexed together
+ on authoring the Annodex format bitstreams. Additional tags or
+ attributes describe other features of the Annodex bitstream
+ such as the time mappings for the start of the file.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT stream (import*)>
+<!ATTLIST stream
+ id ID #IMPLIED
+ basetime %Playbacktime; "0"
+ utc %UTCtime; #IMPLIED
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The "stream" element has no text attributes and thus
+ internationalisation attributes are not required. The "id"
+ attribute follows the default language specified in the "cmml"
+ element.
+ </t>
+
+ <t>The "basetime" attribute contains a playback time in seconds
+ associated with the first data packet of the Annodex
+ bitstream. All other times in the CMML file MUST be calculated
+ relative to this basetime. For example, a basetime of 300
+ seconds npt for a video file implies that the first frame is
+ related to a play time of 300 seconds, and a clip with a start
+ time of 350 seconds is to be included 50 seconds into the
+ Annodex bitstream. If no basetime (or no stream tag) is given,
+ the basetime defaults to 0 npt. The basetime can be given as a
+ SMPTE or NPT time, or as a rational number as in 5/1300, but
+ not as a utc time.
+ </t>
+
+ <t>The "utc" attribute associates a calendar date and a
+ wall-clock time with the basetime. It therefore provides a
+ mapping of the basetime to a real-world clock time and is given
+ as a UTC time. If it is omitted, the start attribute in the
+ import tag, and the start and end attributes in clip tags MUST
+ NOT be specified as UTC times.
+ </t>
+
+ <t>The content model of the "stream" tag then proposes an
+ arbitrary number of input bitstreams. These are described one by
+ one in the "import" element.
+ </t>
+
+ <!--****************-->
+ <!-- Import element -->
+ <!--****************-->
+ <section title="The 'import' tag">
+
+ <t>A "import" tag contains information on one of the input
+ bitstreams for the multiplexing process. It may also contain
+ additional parameters to set up the Annodex encoder for each
+ import bitstream.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT import (param*)>
+<!ATTLIST import
+ %i18n;
+ id ID #IMPLIED
+ title CDATA #IMPLIED
+ granulerate CDATA #IMPLIED
+ contenttype %ContentType; #IMPLIED
+ src %URI; #REQUIRED
+ start %Timestamp; "0"
+ end %Timestamp; #IMPLIED
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The relevant bitstream (fragment) is referenced through the
+ "src" attribute. The src is a URI and may thus also contain a
+ time interval specification in URIs which narrows down the
+ input file to that given subpart. That resource is multiplexed
+ into the Annodex format bitstream starting at the time given
+ in the "start" attribute and ending at the latest at the time
+ given in the "end" attribute. The "start" and "end" attributes
+ are interpreted relative to the timeline of the Annodex format
+ bitstream.
+ </t>
+
+ <t>The internationalisation attributes provide the language of
+ the import element's and the contained param tags' attribute
+ values, such as the "id" attributes and the "title" attribute.
+ </t>
+
+ <t>The optional "title" attribute provides a chance to jot
+ down a human readable comment on the source bitstream. This
+ may e.g. be used in authoring applications for a more human
+ readable display than the "id" tag which is really a key for
+ identifying elements uniquely.
+ </t>
+
+ <t>The "granulerate" attribute contains the base temporal
+ resolution in Hz of the input bitstream refered in the "src"
+ attribute. It depends on the encoding format of the input
+ bitstream and typically contains the framerate for video
+ (e.g. 25 frames/sec) and the samplerate for audio (e.g. 44100
+ samples/sec), but may contain any rational number given with
+ an integer denominator larger than 1 sec (e.g. 25 frames on 2
+ seconds). Each bitstream has its own granulerate dependent on
+ its specific encoding. This attribute is implied as it can be
+ determined automatically during the multiplexing process when
+ the headers of the encoded media bitstream contain this
+ information. For bitstreams without header, such as
+ uncompressed audio, the author of the CMML file can provide
+ the granulerate to the multiplexer in this attribute.
+ </t>
+
+ <t>The "contenttype" attribute specifies the <xref
+ target="ContentType">media type</xref> of the input bitstream
+ refered in the "src" attribute. It is optional as the media
+ type can often be derived from the file name or file header of
+ the media source during multiplexing.
+ </t>
+
+ <t>The "src" attribute specifies a URI to the input
+ bitstream. Commonly used URI schemes are "file" and "http".
+ For specifying temporal subsets of the input bitstream, use
+ the <xref target="timedURI">time interval specification for
+ URIs</xref>.
+ </t>
+
+ <t>The "start" attribute specifies a time in the output
+ Annodex bitstream at which the media bitstream will be
+ inserted. This time is specified with respect to the
+ "basetime" attribute given in the "stream" element.
+ </t>
+
+ <t>The "end" attribute specifies a time in the output Annodex
+ bitstream at which the media bitstream will stop at the
+ latest. This time is also specified with respect to the
+ "basetime" attribute given in the "stream" element. This
+ attribute is not required when the full bitstream is used.
+ </t>
+
+ <t>The content model of the "import" tag then allows an
+ arbitrary number of "param" tags to add as many descriptive
+ parameter values to the mulitplexing activity as necessary.
+ </t>
+
+ </section> <!--import-->
+
+ <!--****************-->
+ <!-- Param element -->
+ <!--****************-->
+ <section title="The 'param' tag">
+
+ <t>A "param" tag is empty, but its attributes contain a
+ name-value pair for describing the input bitstream in the
+ parent "import" element. It inherits its internationalisation
+ from that element, too, to avoid overhead. The "param" element
+ is declared as follows:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT param EMPTY>
+<!ATTLIST param
+ id ID #IMPLIED
+ name CDATA #REQUIRED
+ value CDATA #REQUIRED
+ >
+ ]]></artwork>
+ </figure>
+
+ <a>The "name" attribute identifies a property name. It does
+ not list legal values for this attribute.
+ </a>
+
+ <a>The "value" attribute specifies a property's value. It does
+ not list legal values for this attribute.
+ </a>
+
+ </section> <!--param-->
+
+ </section> <!--stream-->
+
+
+ <!--**************-->
+ <!-- Head element -->
+ <!--**************-->
+ <section title="The cmml 'head' element">
+
+ <t>The CMML "head" element contains annotation information on
+ the complete Annodex bitstream, for whose creation the CMML file
+ is used. It therefore contains header-type information such as a
+ title, style information, related documents and meta information
+ describing the bitstream.
+ </t>
+
+ <t>The "head" element is declared as the following:
+ </t>
+ <figure>
+ <artwork><![CDATA[
+<!ENTITY % head.misc "(style|meta|link)*">
+
+<!ELEMENT head (%head.misc;,
+ ((title, %head.misc;, (base, %head.misc;)?) |
+ (base, %head.misc;, (title, %head.misc;))))>
+<!ATTLIST head
+ %i18n;
+ id ID #IMPLIED
+ profile %URI; #IMPLIED
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The "head" tag must contain a "title" tag. It may contain one
+ "base" tag before or after the "title" tag and any number of
+ "style", "meta", or "link" tags at any position.
+ </t>
+
+ <t>The "%i18n;" attribute specifies the base language of the
+ "head" tag's attribute values.
+ </t>
+
+ <t>The value of the "profile" attribute is a space-separated
+ list of base URIs specifying locations of "meta" tag schemes
+ such as the Dublin Core (see http://dublincore.org/). These
+ schemes may be used in the "meta" elements of the "head" or the
+ "clip" tags.
+ </t>
+
+ <!--***************-->
+ <!-- Title element -->
+ <!--***************-->
+ <section title="The 'title' element">
+
+ <t>The "title" tag gives a descriptive title for the complete
+ Annodex bitstream. It is not considered to be part of the
+ presentation and should be displayed, e.g. as the title of the
+ window that the Annodex bitstream is being displayed in.
+ Exactly one title is required per document.
+ The "title" element is declared as the
+ following:
+ </t>
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT title (#PCDATA)>
+<!ATTLIST title
+ %i18n;
+ id ID #IMPLIED
+>
+ ]]></artwork>
+ </figure>
+
+ <t>The "%i18n;" attribute specifies the base language of the
+ "title" text.
+ </t>
+
+ </section>
+
+ <!--**************-->
+ <!-- Base element -->
+ <!--**************-->
+ <section title="The 'base' element">
+
+ <t>The "base" element defines the base URI of the Annodex
+ bitstream. All relative URIs of the bitstream get interpreted
+ relative to this base. The "base" element is empty, but its
+ attributes contain the base URI. It is declared as follows:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT base EMPTY>
+<!ATTLIST base
+ id ID #IMPLIED
+ href %URI; #REQUIRED
+>
+ ]]></artwork>
+ </figure>
+
+ <t>The "href" attribute contains the base URI. If the "base"
+ element is omitted, the base URI of the Annodex bitstream is
+ derived from the address through which the Annodex bitstream
+ is accessed.
+ </t>
+
+ </section>
+
+
+ <!--**************-->
+ <!-- Meta element -->
+ <!--**************-->
+ <section title="The 'meta' element">
+
+ <t>The "meta" element in the "head" element defines structured
+ annotations for the complete Annodex bitstream. A "meta"
+ element is empty, but its attributes contain the name-value
+ pairs of a structured annotation. The "meta" element is
+ declared as follows:
+ </t>
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT meta EMPTY>
+<!ATTLIST meta
+ %i18n;
+ id ID #IMPLIED
+ name NMTOKEN #IMPLIED
+ content CDATA #REQUIRED
+ scheme CDATA #IMPLIED
+>
+ ]]></artwork>
+ </figure>
+
+ <t>The "%i18n;" attribute specifies the language of the meta
+ attribute and content texts.
+ </t>
+
+ <t>The "name" attribute identifies a property name. It does
+ not list legal values for this attribute.
+ </t>
+
+ <t>The "content" attribute specifies a property's value. It
+ does not list legal values for this attribute.
+ </t>
+
+ <t>The "scheme" attribute names a scheme to be used to
+ interprete the property's value. The scheme can be located via
+ the "profile" attribute in the "head" element.
+ </t>
+
+ </section>
+
+
+ <!--**************-->
+ <!-- Link element -->
+ <!--**************-->
+ <section title="The 'link' element">
+
+ <t>The "link" element in the "head" element defines links to a
+ related external resource. These resources are often used to augment
+ the user agent's ability to process the current document.
+ The "link" element is declared as follows:
+ </t>
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT link EMPTY>
+<!ATTLIST link
+ %attrs;
+ href %URI; #IMPLIED
+ type %ContentType; #IMPLIED
+ rel %LinkTypes; #IMPLIED
+ rev %LinkTypes; #IMPLIED
+ media %MediaDesc; #IMPLIED
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The "attrs;" attribute covers the specification of the language
+ of the title attribute, a unique identifing name, a reference to a
+ style sheet specification, and a title attribute to provides a
+ short description of the relationship between the current document
+ and the one referred to in the "href" attributed.
+ </t>
+
+ <t>The "href" attribute contains a URI reference to a related
+ external resource. These resources are often used to augment
+ the user agent's ability to process the current document.
+ </t>
+
+ <t>The "type" attribute contains a media type specification for
+ the linked document as per <xref target="ContentType">RFC 2045</xref>,
+ e.g. "text/x-css-cmml".
+ </t>
+
+ <t>The "rel" attribute describes the relationship from the
+ current document to the resource specified by the href attribute.
+ The value of this attribute is a space-separated list of link
+ types.
+ </t>
+
+ <t>The "rev" attribute describes a reverse link from the
+ resource specified by the href attribute to the current document.
+ The value of this attribute is a space-separated list of link types.
+ </t>
+
+ <t>The "media" attribute specifies the intended destination device
+ for style information, if the href points to an external style sheet.
+ It may be a single media descriptor or a comma-separated list.
+ The default value for this attribute is "screen".
+ </t>
+
+ </section>
+
+
+ <!--***************-->
+ <!-- Style element -->
+ <!--***************-->
+ <section title="The 'style' element">
+
+ <t>The "style" element in the "head" element contains an internally
+ defined style sheet.
+ The "style" element is declared as follows:
+ </t>
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT style (#PCDATA)>
+<!ATTLIST style
+ %i18n;
+ id ID #IMPLIED
+ title %Text; #IMPLIED
+ type %ContentType; #REQUIRED
+ media %MediaDesc; #IMPLIED
+ xml:space (preserve) #FIXED 'preserve'
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The "i18n;" attribute containt the language of the title attribute.
+ </t>
+
+ <t>The "title" attribute contains a short description of the style in
+ human readable form.
+ </t>
+
+ <t>The "type" attribute contains a media type specification for
+ the linked document as per <xref target="ContentType">RFC 2045</xref>,
+ e.g. "text/x-css-cmml".
+ </t>
+
+ <t>The "media" attribute specifies the intended destination device
+ for the style information.
+ It may be a single media descriptor or a comma-separated list.
+ The default value for this attribute is "screen".
+ </t>
+
+ </section>
+
+ </section>
+
+ <!--****************-->
+ <!-- Clip element -->
+ <!--****************-->
+ <section title="The cmml 'clip' tag">
+
+ <t>A CMML file typically contains a number of sections given
+ through "clip" tags. The CMML "clip" tag contains information
+ about a section of the Annodex bitstream. This is expressed in a
+ number of elements and attributes annotating, indexing, and
+ hyperlinking the section. The "start" and "end" attributes are
+ used to give the insertion time for the clip into the Annodex
+ bitstream.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT clip ((meta|style)*, a?, img?, desc?)>
+<!ATTLIST clip
+ %attrs;
+ track CDATA "default"
+ start %Timestamp; #REQUIRED
+ end %Timestamp; #IMPLIED
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>Any number of "meta" or "style" elements may appear in a clip, and at
+ most one "a" element, one "img" element, and one "desc"
+ element. Though "meta", "style", "a", "img", and "desc" tag are given in
+ a specific order in the DTD, their order is actually random.
+ </t>
+
+ <t>The "%i18n;" attributes part of the "%attrs;" attributes specify
+ the base language for all the clip's attribute values and content
+ elements. Also, a unique identifying name is specified for the clip
+ in the "id" attribute. This name can be used in URIs that point
+ either to the CMML file or the Annodex bitstream created from it,
+ and allow to point straight at the clip. This may either be done
+ as a URI fragment or URI query specification. The "class" attribute
+ provides a space-separated list of style sheet classes, and the
+ "title" attribute a short tooltip-like clip description.
+ </t>
+
+ <t>The "track" attribute specifies the track that this clip
+ belongs to. An annotation track is a set of clips that belong
+ together from a semantic point of view. Clips in the same track
+ must not overlap temporally. A default track must be available
+ always. This track is the one a client (such as a Web browser
+ plugin) will display by default. Other annotation tracks may be
+ created by the document author to describe a more specific
+ content. An example use are different annotation tracks for each
+ speaker in an audio recording of a meeting or tracks of
+ different languages.
+ </t>
+
+ <t>The "start" and "end" attributes specify the time range
+ during which the clip element is defined. This time range is
+ specified with respect to the "basetime" and "utc" attributes
+ given in the "stream" tag. If the "stream" tag does not contain
+ a "utc" specification, "start" and "end" times are not allowed
+ to be given in UTC time. "start" is a required attribute because
+ a clip without a start time is useless. "end" is optional and
+ only required where clips cannot continue on to the following
+ clip.
+ </t>
+
+ <!--**************-->
+ <!-- Meta element -->
+ <!--**************-->
+ <section title="The 'meta' element">
+
+ <t>The "meta" element is specified above in the "head"
+ section. While a "meta" element in the "head" tag provides
+ meta information for the complete Annodex bitstream, the
+ "meta" elements in a "clip" tag only provide meta information
+ for the clip.
+ </t>
+
+ </section>
+
+ <!--***************-->
+ <!-- Style element -->
+ <!--***************-->
+ <section title="The 'style' element">
+
+ <t>The "style" element is specified above in the "head"
+ section. While a "style" element in the "head" tag provides
+ style sheet information for the complete Annodex bitstream, the
+ "style" elements in a "clip" tag only provide style sheet information
+ for the clip.
+ </t>
+
+ </section>
+
+
+ <!--****************-->
+ <!-- Anchor element -->
+ <!--****************-->
+ <section title="The 'a' element">
+
+ <t>The "a" element specifies a link to a related Web resource
+ together with some information on that related resource. The
+ "a" element definition is very closely related to the xhtml
+ "a" element definition with a reduced number of attributes as
+ they make sense for time-continuous data.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT a (#PCDATA)>
+<!ATTLIST a
+ %attrs;
+ href %URI; #REQUIRED
+ >
+ ]]></artwork>
+ </figure>
+
+ <t>The "attrs" attributes specify internationalisation of
+ the anchor's attribute values and of the anchor text, style
+ sheet class, unique id, and a short, textual description of
+ the hyperlink to be given e.g. in tooltips.
+ </t>
+
+ <t>The "href" attribute specifies the location of a Web
+ resource given through a URI. It thus defines a link between
+ the current clip and a resource which the author believes to
+ be connected closely to this clip's content. This might be a
+ html page or another Annodex bitstream clip or an image
+ etc. An "a" element without a "href" attribute is illegal and
+ should be flagged or ignored.
+ </t>
+
+ <t>The text contained in an "a" element (i.e. the anchor text)
+ gives a short textual description of the link specified
+ through the "href" attribute. It explains why the connection
+ between the current clip and the destination URI is made. It
+ may e.g. encourage the viewer to follow the link to "Get more
+ information on blah".
+ </t>
+
+ </section>
+
+
+ <!--*************-->
+ <!-- img element -->
+ <!--*************-->
+ <section title="The 'img' element">
+
+ <t>The "img" element specifies a link to a representative
+ image for the clip. This image should be quite small as it is
+ the representative image (known as "keyframe") for the current
+ clip. This image may be used to visually summarise the content
+ of the clip when a link to it is displayed, e.g. by a search
+ engine or in a table of contents. The "img" element
+ definition is very closely related to the xhtml "img" element
+ definition with a reduced number of attributes as they make
+ sense for time-continuous data.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT img EMPTY>
+<!ATTLIST img
+ %attrs;
+ src %URI; #REQUIRED
+ alt CDATA #IMPLIED
+ >
+ ]]></artwork>
+ </figure>
+
+ <a>The "attrs" attributes specify internationalisation of
+ the image's attribute values, provide an "id" attribute, a
+ short "title" text, and a style sheet "class" for formatting
+ the layout of the image.
+ </a>
+
+ <t>The "src" attribute specifies the location of an image on
+ the Web given through a URI.
+ </t>
+
+ <t>The "alt" attribute specifies alternative text to be
+ displayed instead of the image as required e.g. for
+ accessibility.
+ </t>
+
+ </section>
+
+
+ <!--**************-->
+ <!-- Desc element -->
+ <!--**************-->
+ <section title="The 'desc' element">
+
+ <t>The "desc" tag contains a human readable, textual
+ description of the content of the clip. The "desc" element is
+ declared as the following:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+<!ELEMENT desc (#PCDATA)>
+<!ATTLIST desc
+ %attrs;
+>
+ ]]></artwork>
+ </figure>
+
+ <t>The internationalisation attributes specify the language of
+ the text in the description, the "id" attribute a unique identifier
+ for the element, the "class" attribute a style-sheet mapping, and
+ the "title" attribute a brief description to be displayed in e.g.
+ a table of contents or as caption.
+ </t>
+
+ </section>
+
+ </section>
+
+
+ <!--******************-->
+ <!-- Serialising CMML -->
+ <!--******************-->
+ <section title="Serialising CMML">
+
+ <t>CMML is an annotation language that is meant to markup any
+ time-continuous data and be interleaved in a time-synchronous
+ fashion with other time-continuous bitstreams. Therefore, CMML
+ must be able to be serialised into a time-continuous bitstream
+ of data packets. This is described in this section.
+ </t>
+
+ <t>CMML is serialised by having some initial header pages that
+ set up the CMML decoding environment, and contain header type
+ information. The content of a CMML bitstream then consists of
+ "clip" tags. The "stream" tag is not represented in the CMML
+ bitstream as it controls the authoring of the bitstream that is
+ created by interleaving the CMML with the media streams listed
+ in the "stream" tag. Its information is meant to be stored in the
+ encapsulation format.
+ </t>
+
+ <t>All of the CMML bitstream information is text. As it gets
+ encoded into a binary bitstream, an encoding format has to be
+ specified. To simplify things, UTF-8 is defined as the mandatory
+ encoding format for all data in a CMML binary bitstream. Also,
+ the encoding process MUST ensure that newline characters are
+ represented as LF (or "\n" in C) only and replace any new line
+ representations that come as CR LF combinations (or "\r\n" in C)
+ with LF only.
+ </t>
+
+ <section title="The format of the CMML ident header packet">
+
+ <t>The first header packet of a CMML logical bitstream is the
+ CMML ident header. It contains all information required to identify
+ the CMML bitstream and to set up a CMML decoder. It has the
+ following format:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'CMML\0\0\0\0' | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major | Version minor | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ...
+
+ ]]></artwork>
+ </figure>
+
+
+ <t>The fields in an CMML ident header packet have the following
+ meaning:
+ </t>
+ <list style="numbers">
+ <t>Identifier: a 8 Byte field that identifies this file to
+ be of a CMML logical input bitstream. It
+ contains the magic numbers:
+ <list style="hanging">
+ <t>0x43 'C'</t>
+ <t>0x4d 'M'</t>
+ <t>0x4d 'M'</t>
+ <t>0x4c 'L'</t>
+ <t>0x00 '\0'</t>
+ <t>0x00 '\0'</t>
+ <t>0x00 '\0'</t>
+ <t>0x00 '\0'</t>
+ </list>
+ </t>
+ <t>Version major: 2 Byte short integer number signifying the
+ major version number of the CMML format
+ bitstream.
+ </t>
+ <t>Version minor: 2 Byte short integer number signifying the
+ minor version number of the CMML format
+ bitstream.
+ </t>
+ </list>
+
+ <t>When encapsulating a CMML bitstream, more fields may be added
+ to this header as required by the encapsulation or exchange format.
+ </t>
+
+ </section>
+
+ <section title="The format of the CMML secondary headers">
+
+ <t>The CMML secondary headers are a sequence of
+ two packets that contain the CMML and XML "setup" information:
+ <list typs="symbols">
+ <t>one packet with the CMML xml preamble and "cmml" tag.</t>
+ <t>one packet with the CMML "head" tag.</t>
+ </list>
+ These packets contain textual, not binary information.
+ </t>
+
+ <t>The CMML preamble tags are all single-line tags, such as the
+ xml processing instruction (<![CDATA[<?xml...>]]>) and the
+ document type declaration (<![CDATA[<!DOCTYPE...>]]>).
+ </t>
+
+ <t>The only CMML tag that is not already serialized from a
+ CMML file is the "cmml" tag, as it encloses all the other
+ content tags. To serialise it, the "cmml"
+ start tag is transformed into a processing instruction,
+ retaining all its attributes (<![CDATA[<?cmml ...>]]>), and
+ the "cmml" end tag is deleted.
+ </t>
+
+ <t>The first CMML secondary header packet has the following format:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <?xml ... | 0-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <!DOCTYPE ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <?cmml ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ ]]></artwork>
+ </figure>
+
+ <t>The second CMML secondary header packet contains the
+ CMML head element with all its attributes and other
+ containing elements and has the following format.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <head ... | 0-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | </head> |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ ]]></artwork>
+ </figure>
+
+ </section>
+
+ <section title="The format of the CMML data packets">
+
+ <t>The data packets of the CMML bitstream contain the
+ CMML clip elements. Their "start" and "end" attributes
+ however only exist for authoring purposes and are not
+ copied into the bitstream, but are rather represented
+ through the time mapping of the encapsulation format that
+ interleaves CMML data with data from other time-continuous
+ bitstreams. This avoids contradictory doubly represented
+ timing information. Generally the time mapping is done through
+ some timestamp representation and through the position in
+ the stream.
+ </t>
+
+ <t>A "clip" tag is encoded with all tags (except for the
+ "start" and "end" attributes) as a string printed into a
+ clip packet. The "clip" tag's "start" attribute tells the
+ encapsulator at what time to insert the clip packet into
+ the bitstream. If an "end" attribute is present, it leads to
+ the creation of another clip packet, unless another clip packet
+ starts on the same track beforehand. This clip packet contains
+ an empty "clip" tag, i.e. a "clip" tag without "meta", "a",
+ "img" or "desc" elements and no attribute values except for a
+ copy of the "track" attribute from the original "clip" tag.
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | <clip ... | 0-
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | </clip> |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ ]]></artwork>
+ </figure>
+
+ </section>
+
+ </section>
+
+
+ <!--**************************-->
+ <!-- Encoding CMML to Annodex -->
+ <!--**************************-->
+ <section title="Mapping CMML into Ogg and Annodex">
+
+ <section title="Media mapping for a CMML logical bitstream inside Ogg">
+
+ <t>When mapping a CMML logical bitstream into Ogg, the
+ serialisation as described in the previous section is used as
+ a logical bitstream. The ident packet is extended by a few
+ fields that are necessary for handling the time stamping of
+ the content packets (i.e. the clips) for Ogg. Here is its format:
+ </t>
+
+ <figure>
+ <artwork><![CDATA[
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| Byte
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Identifier 'CMML\0\0\0\0' | 0-3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 4-7
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Version major | Version minor | 8-11
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate numerator | 12-15
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 16-19
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granulerate denominator | 20-23
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | | 24-27
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Granuleshift | 28
+ +-+-+-+-+-+-+-+-+
+
+ ]]></artwork>
+ </figure>
+
+ <t>Fields with more than one byte length are encoded LSB
+ (least significant byte) first.
+ </t>
+
+ <t>The additional fields in an CMML ident header packet for Ogg
+ have the following meaning:
+ </t>
+ <list style="numbers">
+ <t>Granule rate numerator & denominater: 8 Byte integer
+ number each. They represent the temporal resolution of the
+ logical bitstream in Hz given as a rational number in the
+ same way as the fishead basetime field above.
+ </t>
+ <t>Granuleshift: a 1 Byte integer number describing whether to
+ partition the granule_position into two for the CMML logical
+ bitstream, and how many of the lower bits to use for the
+ partitioning. The upper bits then still signify a
+ time-continuous granule position for a directly decodable
+ and presentable data granule. The lower bits allow for
+ specification of the granule position of a previous CMML
+ data packet (i.e. "clip" element), which helps to identify
+ how much backwards seeking is necessary to get to the last
+ and still active "clip" element (of the given track).
+ The granuleshift is therefore the log of the maximum possible
+ clip spacing.
+ </t>
+ </list>
+
+ <t>A default granule rate for CMML is: 1/1000. The default
+ granule shift used is 32, which halfs the granule position to
+ allow for the backwards pointer to be public.
+ </t>
+
+ <t>The media mapping for CMML into Ogg is as follows:
+ <list style="symbols">
+ <t>The bos page MUST contain the extended CMML ident packet.</t>
+ <t>The first secondary header packet of CMML contains the xml
+ preamble as described above.</t>
+ <t>The second secondary header packet contains the CMML "head"
+ tag as described above.</t>
+ <t>The content or data packets for CMML contain the CMML "clip" tags
+ each encoded in their own packet and inserted at the accurate
+ time.</t>
+ <t>The eos page contains a packet with an empty clip tag.</t>
+ </list>
+ </t>
+
+ <t>If CMML is encapsulated in Ogg without the skeleton bitstream,
+ it potentially loses time information. The basetime will then be
+ mapped always to 0 and utc time mappings cannot be represented.
+ It also loses all the message header fields which contain
+ machine-readable meta information on the physical bitstream.
+ </t>
+
+ </section>
+
+ <section title="Using CMML to author Annodex bitstreams">
+
+ <t>As CMML contains authoring information for Annodex bitstreams,
+ a CMML instance document contains more than just the annotation
+ information necessary for the CMML logical bitstream. It also
+ contains control information to create the control section of an
+ Annodex bitstream, i.e. the skeleton bitstream with its secondary
+ header packets describing each of the contained logical bitstreams.
+ Note that we only describe the creation of Annodex Version 3.0
+ bitstreams here.
+ </t>
+
+ <t>The authoring information stems in particular from the "stream" tag
+ plus some specific information from the "cmml" tag. Generally,
+ the "stream" tag's attributes contribute to the skeleton fishead
+ packet, the "import" tag's attributes to the skeleton fisbone
+ packets of each logical bitstream, and the "cmml" tag's attributes
+ to the fisbone of the CMML logical bitstream. While the "cmml" tag
+ is represented in full as a processing instruction in the secondary
+ header packets of the CMML logical bitstream (see above), this is
+ not the case for the "stream" tag. Therefore, this section also
+ contains a description of what tags of the "stream" tag are not
+ used inside an Annodex bitstream.
+ </t>
+
+ <section title="Creating the skeleton ident packet">
+
+ <t>The skeleton ident packet receives the "basetime" and the
+ "utc" field information from the "stream" tag.
+ </t>
+
+ <t>"Basetime numerator & denominator": if the "basetime"
+ attribute is given in a CMML instance document, it MUST be
+ represented in the skeleton ident header in the fields
+ "Basetime numerator" and "Basetime denominator". It is converted
+ from a possible NPT or SMPTE representation to a rational number
+ to be stored in these fishead fields.
+ </t>
+
+ <t>"Presentationtime numerator & denominator": if the "basetime"
+ attribute is given in a CMML instance document, it also
+ determines the presentation time of the interleaved bitstream and
+ the "Basetime numerator" and "Basetime denominator" MUST be
+ copied to the "Presentationtime numerator" and "Presentationtime
+ denominator" fields of the skeleton ident header.
+ </t>
+
+ <t>"UTC": if the "utc" attribute is given in a CMML instance document,
+ it MUST be represented in the skeleton ident header in the "UTC" field.
+ </t>
+
+ </section>
+
+ <section title="Creating the skeleton fisbone packets">
+
+ <t>A fisbone packet for a logical bitstream is created through
+ the authoring information of an "import" tag in a CMML instance
+ document's "stream" tag. One "import" tag contains information
+ on one particular logical bitstream in the interleaved bitstream
+ and thus creates one particular skeleton fisbone packet.
+ </t>
+
+ <t>"Granulerate numerator & denominator": if the "granulerate"
+ attribute is present in the "import" tag, it MUST be represented
+ in the fisbone header for the respective media bitstream in the
+ fields "Granulerate numerator" and "Granulerate denominator".
+ The encoder MUST however ascertain that the values are sensible,
+ and if it knows the accurate granule rate for a logical bitstrea
+ overrun the user input with the one that was used during creation
+ of the interleaved bitstream.
+ </t>
+
+ <t>"Content-type" message header field: this attribute MUST be
+ represented in the respective skeleton fisbone packet as a message header
+ field with name "Content-type", as it signifies the MIME type
+ of the media bitstream, providing for a decoding hint. If the user
+ does not specify the "contenttype" attribute, the encoder
+ MUST provide it during the interleaving process.
+ </t>
+
+ <t>"ID" message header field: if an "id" attribute is specified
+ for an "import" tag, it SHOULD be represented in the skeleton
+ fisbone header for the respecitve media bitstream as a message
+ header field with name "ID", as it signifies a short identifying
+ machine-readable string for the import media bitstream.
+ </t>
+
+ <t>User specified message header fields: if "name" and "value"
+ attributes are specified in the "param" tags of the "import" tag,
+ these MAY be represented in the skeleton fisbone packet of the respective
+ media bitstream as a message header field with the given name-value pair.
+ These fields are highly dependent on the type of media bitstream
+ handled and it therefore depends on the encoding tool to make
+ a selection of the parameters acquired. For example, an
+ audio bitstream that contains speech in a specific language may
+ be identified during CMML authoring through a param element with
+ "Content-Language" name, and acquired into the media bitstream
+ message header field of the same name.
+ </t>
+
+ </section>
+
+ <section title="The CMML fisbone packet fields">
+
+ <t>A CMML instance document that specifies annotations in "head"
+ and "clip" elements does not get to use the "stream" tag to
+ provide encoding hints for its CMML logical bitstream. Its
+ encoding hints come from the "cmml" tag and the "encoding"
+ attribute of the xml processing directive.
+ </t>
+
+ <t>"Number of header packets": this field has a fixed size of 3
+ for the CMML specification given in this document. It counts the
+ CMML ident packet, the XML preamble packet and the head tag packet.
+ </t>
+
+ <t>"Granulerate numerator & denominator": if the "granulerate"
+ attribute is present in the "cmml" tag, it MUST be represented
+ in the fisbone header in the fields "Granulerate numerator" and
+ "Granulerate denominator". The encoder MUST however ascertain
+ that the values are sensible. The value defaults to "1/1000" if
+ it is not specified by the user.
+ </t>
+
+ <t>"Content-type" message header field: the content type for
+ the fisbone packet that describes the CMML logical bitstream is
+ fixed at "text/x-cmml" (or "text/cmml" after IANA registration
+ of the MIME type.
+ </t>
+
+ <t>"charset": if the xml processing directive contains an "encoding"
+ attribute, this MUST be represented in the CMML fisbone packet as an
+ addendum to the message header field "Content-type" as a charset. For
+ example: "Content-type: text/x-cmml; charset=UTF-8".
+ </t>
+
+ <t>"ID" message header field: if an "id" attribute is specified
+ for the "cmml" tag, it SHOULD be represented in the skeleton
+ fisbone header for CMML as a message
+ header field with name "ID", as it signifies a short identifying
+ machine-readable string for the import media bitstream.
+ </t>
+
+ <t>"Content-Language" and "Content-Dir" message header fields: if
+ the "lang" and "dir" attributes are given in a "cmml" tag, they
+ MUST be represented in the fishbone packet of the CMML bitstream
+ as message header fields with name "Content-Language" and "Content-Dir".
+ </t>
+
+ </section>
+
+ <section title="Usage of the 'stream' tag">
+
+ <t>Here is a list of the attribute values of the
+ "stream" tag and how they are being used:
+ <list>
+ <t>id: not used, as this attribute is only used to enable
+ addressing of the stream tag the XML way (e.g. XPath).
+ It is not relevant for the encoded bitstream and will
+ therefore be lost on encoding.
+ </t>
+
+ <t>basetime: this attribute maps to the skeleton
+ ident header fields "Basetime numerator" and "Basetime
+ denominator".
+ </t>
+
+ <t>utc: this attribute maps to the skeleton ident
+ header field "UTC".</t>
+ </list>
+ </t>
+
+ <t>Here is a list of the attribute values of the
+ "import" tag and how they are being used:
+ <list>
+ <t>id: this attribute may be represented as a message header field
+ in the respective skeleton fisbone packet.
+ </t>
+
+ <t>lang, dir: not used, as these attributes signify the language
+ and directionality of the human readable texts in the stream tag
+ which are not acquired into the Annodex bitstream.</t>
+
+ <t>granulerate: this attribute is used in the skeleton
+ fisbone header fields "Granule rate numerator" and "Granule
+ rate denominator" as well as for the "Presentationtime numerator"
+ and "Presentationtime denominator".
+ </t>
+
+ <t>contenttype: this attribute is represented in the
+ respective skeleton fisbone packet as a message header
+ field with name "Content-type".
+ </t>
+
+ <t>src: not used, as this attribute only points to the location
+ of the import media bitstream and is thus pure authoring
+ information.</t>
+
+ <t>start, end: not used, as this attribute only specifies the
+ segment of the import media bitstream that is to be used during
+ authoring.</t>
+
+ <t>title: not used, as this attribute provides a human readable
+ comment on the import bitstream for authoring purposes.</t>
+ </list>
+ </t>
+
+ <t>Here is a list of the attribute values of the
+ "param" tag list and how they are being used:
+ <list>
+ <t>id: not used, as this attribute is only used to enable
+ addressing of the param tag the XML way (e.g. XPath).
+ It is not relevant for the encoded bitstream and will
+ therefore be lost on encoding.
+ </t>
+
+ <t>name, value: these attributes may be represented in the
+ skeleton fisbone packet of the respective media bitstream
+ as a message header field with the given name-value pair.
+ </t>
+ </list>
+ </t>
+ </section>
+
+ </section>
+
+ </section>
+
+ <!--**************************-->
+ <!-- Decoding ANNODEX to CMML -->
+ <!--**************************-->
+ <section title="Extracting CMML from Annodex bitstreams">
+
+ <t>The decoding of an Annodex format bitstream to CMML is roughly
+ inverse to the encoding an Annodex format bitstream from a CMML
+ file. There are some special cases to take care of, therefore
+ the decoding steps are outlined in order here.
+ </t>
+
+ <section title="Extracting the preamble, 'head' and 'clip' tags">
+
+ <t>The data encoded in the CMML logical bitstream conists of the
+ xml preamble, the "cmml" tag, the "head" tag, and the "clip" tags.
+ These are fairly straightforward to extract.
+ </t>
+
+ <t>xml preamble and "cmml" tag: The xml preamble is constructed
+ from the second header packet of the CMML logical bitstream. It contains
+ the full xml preamble. It also contains the "cmml" processing
+ instruction, which MUST be transformed back to a normal element
+ and an end "cmml" tag be added at the end of the created CMML document.
+ </t>
+
+ <t>"head" tag: The "head" tag is constructed from the third header packet
+ of the CMML logical bitstream, which contains the complete content
+ of the "head" element.
+ </t>
+
+ <t>"clip" tags: The "clip" tags are constructed from the content
+ of the CMML logical bitstream. Each packet contains a "clip" tag
+ with all of the information except for the timing information.
+ A decoder MUST take care to add the start time of each "clip"
+ element into the "start" attribute of the respective CMML "clip" tag.
+ The start time will be calculated from the granulerate in the
+ CMML fisbone packet and the granulepos given in the respective
+ "clip" Ogg packet. Empty "clip" tags should also be converted to
+ end time attributes of the previous "clip" tag on the same track.
+ </t>
+
+ </section>
+
+ <section title="Creating a 'stream' tag">
+
+ <t>The creation of a "stream" tag is not necessary to extract the
+ content of the CMML logical bitstream and thus a textual representation
+ of the interleaved bitstream. However, if the Annodex bitstream has
+ a non-zero "basetime" or a non-null "utc" time in the skeleton
+ ident header, a "stream" tag will allow accurate time information
+ in the CMML file and SHOULD be created with these attribute values.
+ </t>
+
+ <t>If a "stream" tag is created with the "basetime" and "utc" attributes,
+ it is empty by default. A ripping application MAY however extract all
+ the data bitstreams out of the Annodex bitstream into files, and then
+ reference these files in the "src" attribute of "import" tags.
+ </t>
+
+ <t>Other attributes of the "import" tags MAY also be filled in from
+ the logical bitstreams:
+ <list style="symbols">
+ <t>the "contenttype" attribute from the "Content-type" Message
+ header field of the respective skeleton secondary header packet,</t>
+ <t>the "granulerate" attribute from the Granulerate fields of
+ the respecitive skeleton secondary header packet,</t>
+ <t>the "id" attribute from a Message header field called "ID"
+ if available,</t>
+ <t>and "param" elements from all the remaining Message header fields
+ of the respective skeleton secondary header packet, where the field
+ name is stored in the "name" attribute and the value in the
+ "value" attribute.</t>
+ </list>
+ </t>
+
+ <t>A stream tag will thus roughly be created like this:
+<figure>
+<artwork><![CDATA[
+<stream basetime="[Basetime]" utc="[UTC]">
+ <import id="[ID]"
+ granulerate="[Granulerate numerator/Granulerate denominator]"
+ contenttype="[Content-type message header value]"
+ src="[stream1.ogg]"
+ start="0">
+ <param name="[message header name]" value="[message header value]"/>
+ </import>
+</stream>
+]]></artwork>
+</figure>
+ </t>
+
+ </section>
+
+ </section>
+
+
+ <!--***********************-->
+ <!-- MIME type application -->
+ <!--***********************-->
+ <section title="MIME media type registration for 'text/cmml'">
+
+ <t>This section contains the registration information for the
+ 'text/cmml' media type. While this media type is not approved by
+ the IANA, 'text/x-cmml' may be used to identify CMML instance
+ documents.
+ </t>
+
+ <t>To: ietf-types at iana.org
+ </t>
+
+ <t>Subject: Registration of MIME media type 'text/cmml'
+ </t>
+
+ <t>MIME media type name: text
+ </t>
+
+ <t>MIME subtype name: cmml
+ </t>
+
+ <t>Required parameters: none
+ </t>
+
+ <t>Optional parameters: charset (as in the <xref
+ target="text/xml">text/xml media type</xref>).
+ </t>
+
+ <t>Encoding Considerations: as appropriate for the charset and
+ the transport mechanism (see <xref target="text/xml">text/xml
+ media type</xref>).
+ </t>
+
+ <t>Security considerations: see next section.
+ </t>
+
+ <t>Interoperability considerations: CMML is a free specification
+ that is independent of any media encoding format. It is designed
+ to provide interoperability with existing XML tools and
+ systems. Its specification is not patented and can be
+ implemented by third parties without patent considerations.
+ </t>
+
+ <t>Additional information:</t>
+ <list style="none">
+ <t>Magic numbers: none. However, CMML files start with the XML
+ preamble as any <xref target="text/xml">XML document</xref>)
+ and will also have the string <![CDATA['<cmml']]> near the
+ beginning of the file.</t>
+
+ <t>File extension: .cmml</t>
+
+ <t>Macintosh File Type Code: "TEXT"</t>
+
+ <t>Intended usage: COMMON</t>
+ </list>
+
+ <section title="URI addressing into CMML files">
+
+ <t>There are two ways of hyperlinking via URIs into CMML
+ files: via specification of a temporal interval or via
+ specification of a clip. Both of these ways of addressing are
+ supported for URI queries and URI fragments on CMML files.
+ A server that is capable of supporting these URI queries
+ indicates this by adding the X-Accept-TimeURI header field
+ to its response header fields as defined in the <xref
+ target="timedURI">temporal URI query specification</xref>.
+ </t>
+
+ <section title="Query parameters for use with the http protocol server-side">
+ <t>For the purposes of URI queries on CMML files, it is
+ assumed that the query string takes the format of a CGI
+ query string. The Common Gateway Interface, or CGI, is a
+ standard for external gateway programs to interface with
+ information servers such as HTTP servers (see
+ http://hoohoo.ncsa.uiuc.edu/cgi/). This query string is
+ expected to be interpreted by the HTTP server to return a
+ valid CMML file that differs from the original CMML file
+ only by reducing the set of clip tags to the specified
+ interval.
+ </t>
+
+ <t><b>Temporal query parameter specification:</b></t>
+
+ <t>Addressing of temporal intervals of CMML files is
+ possible through specification of <xref
+ target="timedURI">temporal query intervals in
+ URIs</xref>. An example is the following URI:
+ http://www.blah.au/sample.cmml?t="npt:4" , which relates to
+ the last clip whose start time is just before the given
+ temporal offset and all the clips thereafter.
+ </t>
+
+ <t><b>Clip specification:</b></t>
+
+ <t>Addressing of a clip is possible through specification of
+ the clip's id attribute value. An example is the following
+ URI: http://www.blah.au/sample.cmml?id="dolphin" , which
+ relates to the clip whose id attribute value is
+ "dolphin". Note that id attribute values of all elements
+ have to be unique throughout a XML file (and thus also
+ throughout a CMML file).</t>
+ </section>
+
+ <section title="Fragment identifiers for use with the http protocol client-side">
+ <t>For the purposes of URI fragment specifications on CMML
+ files, it is assumed that the fragment gets interpreted by
+ the HTTP client after the retrieval action. The HTTP client
+ is expected to restrict the usage of the resource to the
+ specified interval.
+ </t>
+
+ <t><b>Temporal fragment specification:</b></t>
+
+ <t>Addressing of temporal intervals of CMML files is
+ possible through specification of <xref
+ target="timedURI">temporal fragments in URIs</xref> An
+ example is the following URI:
+ http://www.blah.au/sample.cmml#npt:4 . This then relates to
+ the last clip whose start time is just before the given
+ temporal offset and all the clips thereafter. This may
+ e.g. be useful to do a zoom into a retrieved CMML resource.
+ </t>
+
+ <t><b>Clip specification:</b></t>
+
+ <t>The values of the id attribute of the clip tags can be
+ used for addressing media clips directly through fragment
+ identifiers as in http://www.blah.au/sample.cmml#dolphin.
+ </t>
+ </section>
+
+ </section>
+
+ </section>
+
+
+ <!--**********-->
+ <!-- Security -->
+ <!--**********-->
+ <section title="Security considerations">
+
+ <t>As CMML is a markup language created by using XML, the same
+ security considerations that apply to <xref
+ target="text/xml">XML</xref>, apply to CMML.
+ </t>
+
+ <t>As the CMML is an authoring language for Annodex format
+ bitstreams, there is no executable code attached to this
+ language. The implementation of a multiplexer to actually create
+ an Annodex bitstream must be careful when handling input
+ bitstreams, which are binary data.
+ </t>
+
+ </section>
+
+ </middle>
+
+ <back>
+
+ <!--************-->
+ <!-- References -->
+ <!--************-->
+ <references>
+
+ <reference anchor="XML" target="http://www.w3.org/TR/2000/REC-xml-20001006">
+ <front>
+ <title>Extensible Markup Language (XML) 1.0</title>
+ <author>
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="October" year="2000" />
+ </front>
+ <seriesInfo name="W3C" value="XML" />
+ </reference>
+
+ <reference anchor="HTML" target="http://www.w3.org/TR/html4/">
+ <front>
+ <title>HTML 4.01 Specification</title>
+ <author>
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="December" year="1999" />
+ </front>
+ <seriesInfo name="W3C" value="HTML" />
+ </reference>
+
+ <reference anchor="XHTML" target="http://www.w3.org/TR/xhtml1/">
+ <front>
+ <title>XHTML(TM) 1.0 The Extensible Hyper Text Markup Language</title>
+ <author>
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>timbl at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="January" year="2000" />
+ </front>
+ <seriesInfo name="W3C" value="XHTML" />
+ </reference>
+
+ <reference anchor="CSS" target="http://www.w3.org/TR/REC-CSS1/">
+ <front>
+ <title>Cascading Style Sheets, level 1</title>
+ <author initials="H.W." surname="Lie" fullname="Hakon Wium Lie">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>howcome at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <author initials="B." surname="Bos" fullname="Bert Bos">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>bbos at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="January" year="1999" />
+ </front>
+ <seriesInfo name="W3C" value="CSS" />
+ </reference>
+
+ <reference anchor="CSS2" target="http://www.w3.org/TR/REC-CSS2/">
+ <front>
+ <title>Cascading Style Sheets, level 2</title>
+ <author initials="B." surname="Bos" fullname="Bert Bos">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>bbos at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <author initials="H.W." surname="Lie" fullname="Hakon Wium Lie">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>howcome at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <author initials="C." surname="Lilley" fullname="Chris Lilley">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>chris at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <author initials="I." surname="Jacobs" fullname="Ian Jacobs">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+ 1 617 253 2613</phone>
+ <facsimile>+ 1 617 258 5999</facsimile>
+ <email>ij at w3.org</email>
+ <uri>http://www.w3c.org</uri>
+ </address>
+ </author>
+ <date month="May" year="1998" />
+ </front>
+ <seriesInfo name="W3C" value="CSS" />
+ </reference>
+
+ <reference anchor="URI" target="http://www.ietf.org/rfc/rfc2396.txt">
+ <front>
+ <title>Uniform Resource Identifiers (URI): Generic Syntax</title>
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 617 253 5702</phone>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>timbl at w3.org</email>
+ </address>
+ </author>
+ <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+ <organization abbrev="UCI">University of California, Irvine</organization>
+ <address>
+ <postal>
+ <street>Department of Information and Computer Science</street>
+ <street>University of California, Irvine</street>
+ <city>Irvine</city> <region>CA</region> <code>92697-3425</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 949 824 7403</phone>
+ <facsimile>+1 949 824 1715</facsimile>
+ <email>fielding at ics.uci.edu</email>
+ </address>
+ </author>
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization>Xerox PARC</organization>
+ <address>
+ <postal>
+ <street>3333 Coyote Hill Road</street>
+ <city>Palo Alto</city> <region>CA</region> <code>94304</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 650 812 4365</phone>
+ <facsimile>+1 650 812 4333</facsimile>
+ <email>masinter at parc.xerox.com</email>
+ </address>
+ </author>
+ <date month="August" year="1998" />
+ </front>
+ <seriesInfo name="RFC" value="2396" />
+ </reference>
+
+ <reference anchor="RTSP" target="Http://www.ietf.org/rfc/rfc2326.txt">
+ <front>
+ <title>Real Time Streaming Protocol (RTSP)</title>
+ <author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
+ <organization abbrev="ColU">Columbia University</organization>
+ <address>
+ <postal>
+ <street>Dept. of Computer Science</street>
+ <street>1214 Amsterdam Avenue</street>
+ <city>New York</city> <region>NY</region> <code>10027</code>
+ <country>US</country>
+ </postal>
+ <email>schulzrinne at cs.columbia.edu</email>
+ </address>
+ </author>
+ <author initials="A." surname="Rao" fullname="Anup Rao">
+ <organization abbrev="NS">Netscape Communications Corp.</organization>
+ <address>
+ <postal>
+ <street>501 E. Middlefield Road</street>
+ <city>Mountain View</city> <region>CA</region> <code>94043</code>
+ <country>US</country>
+ </postal>
+ <email>anup at netscape.com</email>
+ </address>
+ </author>
+ <author initials="R." surname="Lanphier" fullname="Robert Lanphier">
+ <organization>RealNetworks</organization>
+ <address>
+ <postal>
+ <street>1111 Third Avenue Suite 2900</street>
+ <city>Seattle</city> <region>WA</region> <code>98101</code>
+ <country>US</country>
+ </postal>
+ <email>robla at real.com</email>
+ </address>
+ </author>
+ <date month="April" year="1998" />
+ </front>
+ <seriesInfo name="RFC" value="2326" />
+ </reference>
+
+ <reference anchor="LANG" target="http://www.ietf.org/rfc/rfc1766.txt">
+ <front>
+ <title>Tags for the Identification of Languages</title>
+ <author initials="H." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
+ <organization abbrev="UNINETT">UNINETT</organization>
+ <address>
+ <postal>
+ <street>Pb. 6883 Elgeseter</street>
+ <city>Trondheim</city> <code>7002</code>
+ <country>Norway</country>
+ </postal>
+ <email>Harald.T.Alvestrand at uninett.no</email>
+ </address>
+ </author>
+ <date month="March" year="1995" />
+ </front>
+ <seriesInfo name="RFC" value="1766" />
+ </reference>
+
+ <reference anchor="ContentType" target="http://www.ietf.org/rfc/rfc2045.txt">
+ <front>
+ <title>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+ <author initials="N." surname="Freed" fullname="Ned Freed">
+ <organization abbrev="Innosoft">Innosoft Internationl, Inc.</organization>
+ <address>
+ <postal>
+ <street>1050 East Garvey Avenue South</street>
+ <city>West Covina</city> <region>CA</region> <code>91790</code>
+ <country>USA</country>
+ </postal>
+ <email>ned at innosoft.com</email>
+ </address>
+ </author>
+ <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+ <organization abbrev="First Virtual">First Virtual Holdings</organization>
+ <address>
+ <postal>
+ <street>25 Washington Avenue</street>
+ <city>Morristown</city> <region>NJ</region> <code>07960</code>
+ <country>USA</country>
+ </postal>
+ <email>nsb at nsb.fv.com</email>
+ </address>
+ </author>
+ <date month="November" year="1996" />
+ </front>
+ <seriesInfo name="RFC" value="2045" />
+ </reference>
+
+ <reference anchor="text/xml" target="http://www.ietf.org/rfc/rfc2376.txt">
+ <front>
+ <title>XML Media Types</title>
+ <author initials="E." surname="Whitehead" fullname="E. James Whitehead, Jr.">
+ <organization abbrev="UC Irvine">University of California, Irvine</organization>
+ <address>
+ <postal>
+ <street>Department of Information and Computer Science</street>
+ <city>Irvine</city> <region>CA</region> <code>92697-3425</code>
+ <country>USA</country>
+ </postal>
+ <email>ejw at ics.uci.edu</email>
+ </address>
+ </author>
+ <author initials="M." surname="Murata" fullname="Murata Makoto (Family Given)">
+ <organization abbrev="Fuji Xerox">Fuji Xerox Information Systems</organization>
+ <address>
+ <postal>
+ <street>KSP 9A7, 2-1, Sakado 3-chome, Takatsu-ku</street>
+ <city>Kawasaki-shi</city> <region>Kanagawa-ken</region> <code>213</code>
+ <country>Japan</country>
+ </postal>
+ <email>murata at fxis.fujixerox.co.jp</email>
+ </address>
+ </author>
+ <date month="July" year="1998" />
+ </front>
+ <seriesInfo name="RFC" value="2376" />
+ </reference>
+
+ <reference anchor="SMPTE">
+ <front>
+ <title>SMPTE STANDARD for Television, Audio and Film - Time and Control Code</title>
+ <author>
+ <organization abbrev="SMPTE"> The Society of Motion Picture and Television Engineers</organization>
+ <address>
+ <postal>
+ <street>595 W. Hartsdale Ave.</street>
+ <city>White Plains</city> <region>NY</region> <code>10607</code>
+ <country>USA</country>
+ </postal>
+ <email>smpte at smpte.org</email>
+ </address>
+ </author>
+ <date month="September" year="1999" />
+ </front>
+ <seriesInfo name="ANSI" value="12M-1999" />
+ </reference>
+
+ <reference anchor="ISO8601">
+ <front>
+ <title>Data elements and interchange formats -- Information interchange -- Representation of dates and times</title>
+ <author initials="TC154" surname="ISO" fullname="ISO - Technical Committee TC 154">
+ <organization abbrev="ISO"> International Organization for Standardization</organization>
+ <address>
+ <postal>
+ <street>1 rue de Varembre</street>
+ <street>Case Postale 56</street>
+ <city>Geneva</city> <region>20</region> <code>1211</code>
+ <country>CH</country>
+ </postal>
+ <email>central at iso.org</email>
+ </address>
+ </author>
+ <date month="" year="2000" />
+ </front>
+ <seriesInfo name="ISO" value="8601" />
+ </reference>
+
+ <reference anchor="timedURI" target="http://www.annodex.net/TR/URI_fragments.txt">
+ <front>
+ <title>Specifying time intervals in URI queries and fragments of time-based Web resources (BCP) (work in progress)</title>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Silvia.Pfeiffer at csiro.au</email>
+ <uri>http://www.annodex.net</uri>
+ </address>
+ </author>
+ <author initials="C." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Conrad.Parker at csiro.au</email>
+ <uri>http://www.annodex.net</uri>
+ </address>
+ </author>
+ <author initials="A." surname="Pang" fullname="Andre T. Pang">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Andre.Pang at csiro.au</email>
+ <uri>http://www.annodex.net</uri>
+ </address>
+ </author>
+ <date month="December" year="2003" />
+ </front>
+ <seriesInfo name="I-D" value="draft-pfeiffer-temporal-fragments-02.txt" />
+ </reference>
+
+ <reference anchor="ANX" target="http://www.annodex.net/TR/cmml.txt">
+ <front>
+ <title>The Annodex annotation and indexing format for time-continuous data files, Version 1.0 (work in progress)</title>
+ <author initials="S." surname="Pfeiffer" fullname="Silvia Pfeiffer">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Silvia.Pfeiffer at csiro.au</email>
+ <uri>http://www.annodex.net</uri>
+ </address>
+ </author>
+ <author initials="C." surname="Parker" fullname="Conrad D. Parker">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Conrad.Parker at csiro.au</email>
+ <uri>http://www.annodex.net</uri>
+ </address>
+ </author>
+ <author initials="A." surname="Pang" fullname="Andre T. Pang">
+ <organization abbrev="CSIRO">Commonwealth Scientific and Industrial Research Organisation</organization>
+ <address>
+ <postal>
+ <street>Locked Bag 17</street>
+ <city>North Ryde</city> <region>NSW</region> <code>2113</code>
+ <country>Australia</country>
+ </postal>
+ <phone>+ 61 2 9325 3100</phone>
+ <facsimile>+ 61 2 9325 3200</facsimile>
+ <email>Andre.Pang at csiro.au</email>
+ <uri>http://www.annodex.net</uri>
+ </address>
+ </author>
+ <date month="December" year="2003" />
+ </front>
+ <seriesInfo name="I-D" value="draft-pfeiffer-annodex-01.txt" />
+ </reference>
+
+ </references>
+
+ <!--**********-->
+ <!-- CMML DTD -->
+ <!--**********-->
+ <section title="CMML DTD">
+
+ <figure>
+ <artwork><![CDATA[
+INCLUDE DTD HERE
+ ]]></artwork>
+ </figure>
+
+ </section>
+
+ <!--*****************-->
+ <!-- Sample document -->
+ <!--*****************-->
+ <section title="An example CMML document">
+
+ <figure>
+ <artwork><![CDATA[
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<!DOCTYPE cmml SYSTEM "cmml.dtd">
+
+<cmml lang="en">
+
+<stream basetime="0">
+ <import contenttype="video/mpeg" src="fish.mpg" start="0"/>
+</stream>
+
+<head>
+ <title>Types of fish</title>
+ <meta name="Producer" content="Joe Ordinary"/>
+ <meta name="DC.Author" content="Joe's friend"/>
+</head>
+
+<clip id="intro" start="0">
+ <a href="http://www.blah.au/fish.html">Read more about fish</a>
+ <desc>This is the introduction to the film Joe made about fish.</desc>
+</clip>
+
+<clip id="dolphin" start="npt:3.5" end="npt:5:5.9">
+ <img src="dolphin.jpg"/>
+ <desc>Here, Joe caught sight of a dolphin in the ocean.</desc>
+ <meta name="Subject" content="dolphin"/>
+</clip>
+
+<clip id="goldfish" start="npt:5:5.9">
+ <a href="http://www.blah.au/morefish.anx?id=goldfish">More video clips on goldfish.</a>
+ <img src="http://www.blah.au/goldfish.jpg"/>
+ <desc>Joe has a fishtank at home with many colourful fish. The common goldfish is one of them and Joe's favourite. Here are some fabulous pictures he has taken of them.</desc>
+ <meta name="Location" content="Joe's fishtank"/>
+ <meta name="Subject" content="goldfish"/>
+</clip>
+
+</cmml>
+
+ ]]></artwork>
+ </figure>
+
+ </section>
+
+ <!--*************************-->
+ <!-- Terms and abbreviations -->
+ <!--*************************-->
+ <section title="Definitions of terms and abbreviations">
+ <t>
+ <list style="hanging">
+
+ <t hangText="Mark-up:">XML tags and their content used to
+ describe a document.</t>
+
+ <t hangText="Annotating:">The task of authoring mark-up for
+ a document thus creating a Web resources.</t>
+
+ <t hangText="Hyperlinking:">The task of linking from one Web
+ resource to another. When a link contains a fragment offset
+ into a resource, this is called "deep hyperlinking".</t>
+
+ <t hangText="Clip:">A section of a time-continuous document
+ covering some temporal interval.</t>
+
+ <t hangText="Indexing:">The task of identifying index points
+ or clips for time-continuous documents.</t>
+
+ <t hangText="Annotation track:">A set of clips representing
+ semantically correlated annotations of a time-continuous
+ resource.</t>
+
+ <t hangText="Annodex bitstream:">A specific file format for
+ storing annotation, hyperlinking, and indexing information
+ in annotation tracks and multiplexed together with the
+ time-continuous documents they describe.</t>
+
+ <t hangText="Bitstream:">A sequence of data containing
+ samples of a time-continous document.</t>
+
+ <t hangText="Time-continuous document:">A file containing
+ time-sampled data in a temporally sequential manner.</t>
+
+ </list>
+ </t>
+ </section>
+
+
+ <!--**********-->
+ <!-- Acronyms -->
+ <!--**********-->
+ <section title="Glossary of acronyms">
+ <t>
+ <list style="hanging">
+
+ <t hangText="Annodex:">Annotated and indexed bitstream format.</t>
+
+ <t hangText="CMML:">Continuous Media Markup Language.</t>
+
+ <t hangText="CSS:">Cascading Style Sheets.</t>
+
+ <t hangText="DTD:">Document Type Declaration.</t>
+
+ <t hangText="XML:">eXtensible Markup Language.</t>
+
+ <t hangText="Web:">World Wide Web.</t>
+
+ <t hangText="URI:">Unified Resource Identifier.</t>
+
+ </list>
+ </t>
+ </section>
+
+ <!--*************************-->
+ <!-- IPR and TM -->
+ <!--*************************-->
+<!--
+ <section title="Intellectual Property Rights and the Annodex(TM) Trademark">
+
+ <t>The specifications for the CMML and for the Annodex file
+ format are published openly as the aim is to enable
+ interoperability of applications that follow the CMML and the
+ Annodex specifications, especially in the context of the
+ Internet. CSIRO has registered a trade mark on the word
+ "Annodex" to protect the name from being used for technology
+ that is not interoperable with these specifications. We
+ encourage all conformant implementations of the technology to
+ use the word "Annodex" freely when talking about the file
+ format.</t>
+
+ </section>
+-->
+
+ <!--******************-->
+ <!-- Acknowledgements -->
+ <!--******************-->
+ <section title="Acknowledgements">
+ <t>The authors greatly acknowledge the contributions of Zentaro
+ Kavanagh, Andrew Nesbit and Simon Lai in developing this
+ specification.
+ </t>
+ </section>
+
+
+ </back>
+</rfc>
\ No newline at end of file
Property changes on: standards/draft-pfeiffer-v2-update.xml
___________________________________________________________________
Name: svn:executable
+ *
--
silvia
More information about the cvs-annodex
mailing list