added first draft of the tv profile. tv-src.html is the re-spec soruce, tv.html the generated html document
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/tvprofile/tv-src.html Wed Jan 04 14:28:13 2012 +0100
@@ -0,0 +1,200 @@
+<!DOCTYPE html>
+<html>
+ <head>
+ <title>Web&TV meta-profile (provisional title)</title>
+ <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+ <script src='http://dev.w3.org/2009/dap/ReSpec.js/js/respec.js' class='remove'></script>
+ <script class='remove'>
+
+ var respecConfig = {
+ preProcess : [],
+
+ // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
+ specStatus: "unofficial",
+
+ // the specification's short name, as in http://www.w3.org/TR/short-name/
+ shortName: "tv-profile",
+
+ // if your specification has a subtitle that goes below the main
+ // formal title, define it here
+ subtitle : "Guidelines for integration of interactive TV services in a Browser-based environment",
+
+ // if you wish the publication date to be other than today, set this
+ // publishDate: "2009-08-06",
+
+ // if the specification's copyright date is a range of years, specify
+ // the start date here:
+ // copyrightStart: "2005"
+
+ // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
+ // and its maturity status
+ // previousPublishDate: "1977-03-15",
+ // previousMaturity: "WD",
+
+ // if there a publicly available Editor's Draft, this is the link
+ edDraftURI: "",
+
+ // if this is a LCWD, uncomment and set the end of its review period
+ // lcEnd: "2009-08-05",
+
+ // if you want to have extra CSS, append them to this list
+ // it is recommended that the respec.css stylesheet be kept
+ extraCSS: ["http://dev.w3.org/2009/dap/ReSpec.js/css/respec.css"],
+
+ // editors, add as many as you like
+ // only "name" is required
+ editors: [
+ { name: "Giuseppe Pascale", url: "",
+ company: "Opera", companyURL: "http://www.opera.com/" },
+ ],
+ // authors, add as many as you like.
+ // This is optional, uncomment if you have authors as well as editors.
+ // only "name" is required. Same format as editors.
+
+ //authors: [
+ // { name: "Your Name", url: "http://example.org/",
+ // company: "Your Company", companyURL: "http://example.com/" },
+ //],
+
+ // name of the WG
+ wg: "Web and TV IG",
+
+ // URI of the public WG page
+ wgURI: "http://www.w3.org/2011/webtv/",
+
+ // name (with the @w3c.org) of the public mailing to which comments are due
+ wgPublicList: "public-web-and-tv@w3.org",
+
+ // URI of the patent status for this WG, for Rec-track documents
+ // !!!! IMPORTANT !!!!
+ // This is important for Rec-track documents, do not copy a patent URI from a random
+ // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
+ // Team Contact.
+ wgPatentURI: "",
+ };
+
+ </script>
+ </head>
+ <body>
+<section id='abstract'>
+
+</section>
+
+<section class="informative">
+<h2>Introduction</h2>
+
+ <section>
+ <h2>Background</h2>
+
+ In the past decades, many attempts have been made to create profiles suitable for use in a specific market and/or region, particularly in the TV space, by external organizations. These groups have created documents which are supersets, subsets or both of several W3C specifications. Often these documents have been developed without a direct involvement of relevant W3C working groups. Furthermore not always these different groups were aware of each other, leading to different profiles in different regions and markets. In some cases also extensions to web standards have been designed by different groups, leading to multiple incompatible solutions addressing the same use case.
+
+ By working on a common meta-profile within W3C it becomes easier to closely align external organizations with W3C and with each other. It also allows the W3C to move this profile forward on a regular basis to avoid obsolescence. While is not possible to provide a profile that cover all needs of different organizations and stakeholder, this documents tries to provide a meta-profile that try to keep at a minimum the variables involved in defining such profiles, making it a base that each external organization can use as a component.
+ </section>
+
+ <section>
+ <h2>Audience</h2>
+ </section>
+
+ <section>
+ <h2>Scope</h2>
+ </section>
+
+</section>
+
+<section class="informative">
+<h2>Goals</h2>
+This sections list the goals that have driven the work on this document.
+
+ <section>
+ <h2>Avoid obsolesce</h2>
+ In the past decades, many attempts have been made to create profiles suitable for use in a specific market and/or region, particularly in the TV space, by external organizations. These groups have created documents which are supersets, subsets or both of several W3C specifications. Often, these external documents become obsolete when the W3C improves the related specifications since the W3C has little or no knowledge of these external documents. By working on a common TV profile within W3C it becomes easier to closely align external organizations with W3C and with each other and allows the W3C to move this profile forward on a regular basis to avoid obsolescence.
+ </section>
+
+ <section>
+ <h2>Avoid fragmentation</h2>
+ Use of web technologies in different markets and regions to create interactive TV services is increasing. Different organizations and companies have have defined their own profiles of web technologies that can be used in a given ecosystem to author content. These profiles are supersets, subsets or both of several W3C specifications. The proliferation of such profiles is making challenging to write content that works well across devices. By working on a common TV profile within W3C it becomes easier to closely align ongoing efforts of web based TV services in order to avoid fragmentation.
+ </section>
+
+ <section>
+ <h2>Coordinate deployments</h2>
+ The range of technologies available for web applications developers is so theoretically wide. In practice content developers have to fight with different levels of support of different specification by different devices. This is inevitable since each implementer necessarily need to make a choice on what to implement and when. While in some ecosystems is fine to leave to each implementer to choose his own roadmap, in other ecosystems there is a need for coordination in order to harmonize the development cycle of the different stakeholders (CE manufacturers, Content providers, Content Authors, etc.) and provide a good user experience.
+ </section>
+
+ <section>
+ <h2>Provide a complete application environment</h2>
+ Many W3C specifications leave intentionally undefined some components that are essential to build a full application environment for interactive TV services. For example, the [[HTML5]] specification rely on "relevant specifications" to define rules for processing and rendering data coming from a media stream via an in-band track. Other examples of "variables" that are not specified in [[HTML5]] are supported video codecs or image formats. The same apply to other specifications. Furthermore to provide a complete application environment, different specifications needs to be combined into one product, increasing the number of options and hence the level of fragmentation. This document aims to combine together relevant specification to provide a complete environment that can be used by different organization as application environment for their interactive TV services.
+ </section>
+
+ <section>
+ <h2>Do not reinvent the wheel</h2>
+ Some groups (both inside and outside W3C) have done an analysis of available web technologies in order to see if they were suitable to cover relevant use cases. Often what at a first look was identified as a gap in the web platform is resulted in actually being already supported reusing existing specifications. Since many use cases are common among different regions and organization, by making the result of such analysis available in one document the risk that different groups defines new technologies to cover areas that are already well covered by existing specification (hence causing fragmentation) is reduced.
+ </section>
+
+ <section>
+ <h2>A tunable meta-profile</h2>
+ A profile document is generally beneficial for the industry because it provides a common environment that all different stake holders can rely on with the ultimate goal of providing the best possible user experience. In doing this, several things need to be considered that sometimes goes beyond technical standard activities and is rather close to business model of stake holders. Furthermore, there are many different devices capable of presenting interactive TV services with different hardware capabilities that may also vary over time. Is then impossible to find a profile that suites all business models and devices, is possible to keep such differences at a minimum, identifying all the common parts in a meta profile that can be tuned as needed by other organizations.
+ </section>
+
+</section>
+
+<section>
+<h2>Overview</h2>
+
+ <section>
+ <h2>System Architecture</h2>
+
+ </section>
+ <section>
+ <h2>Components and interfaces</h2>
+ </section>
+</section>
+
+<section>
+<h2>Application Model</h2>
+
+</section>
+
+<section>
+ <h2>User Experience</h2>
+
+ <section>
+ <h2>Content Developers Guidelines</h2>
+ </section>
+
+ <section>
+ <h2>Input Methods</h2>
+ <section>
+ <h2>Traditional Remote Controls</h2>
+ </section>
+ <section>
+ <h2>Touch screens</h2>
+ </section>
+ <section>
+ <h2>Mouse and Keyboard</h2>
+ </section>
+ <section>
+ <h2>Other input devices</h2>
+ </section>
+ </section>
+
+</section>
+
+<section>
+ <h2>Formats and Protocols</h2>
+</section>
+
+
+<section class='appendix'>
+ <h2>Acknowledgements</h2>
+ <p> Thanks to ... for their contributions to this document</p>
+ <p> Thanks to participants of the following groups for their feedbacks: Web and TV Interest Group</p>
+</section>
+
+ </body>
+</html>
+
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/tvprofile/tv.html Wed Jan 04 14:28:13 2012 +0100
@@ -0,0 +1,599 @@
+<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
+<html lang="en" dir="ltr">
+<head>
+ <title>Web&TV meta-profile (provisional title)</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+ <!--
+ === NOTA BENE ===
+ For the three scripts below, if your spec resides on dev.w3 you can check them
+ out in the same tree and use relative links so that they'll work offline,
+ -->
+
+
+ <style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl::before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+table.parameters, table.exceptions {
+ border-spacing: 0;
+ border-collapse: collapse;
+ margin: 0.5em 0;
+ width: 100%;
+}
+table.parameters { border-bottom: 1px solid #90b8de; }
+table.exceptions { border-bottom: 1px solid #deb890; }
+
+.parameters th, .exceptions th {
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+ font-family: initial;
+ font-weight: normal;
+ text-shadow: #666 1px 1px 0;
+}
+.parameters th { background: #90b8de; }
+.exceptions th { background: #deb890; }
+
+.parameters td, .exceptions td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+ vertical-align: top;
+}
+
+.parameters tr:first-child td, .exceptions tr:first-child td {
+ border-top: none;
+}
+
+.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
+ width: 100px;
+}
+
+.parameters td.prmType {
+ width: 120px;
+}
+
+table.exceptions table {
+ border-spacing: 0;
+ border-collapse: collapse;
+ width: 100%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue::before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note::before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+</style><link href="http://www.w3.org/StyleSheets/TR/w3c-unofficial" rel="stylesheet" type="text/css" charset="utf-8"></head>
+ <body style="display: inherit; "><div class="head"><p></p><h1 class="title" id="title">Web&TV meta-profile (provisional title)</h1><h2 id="subtitle">Guidelines for integration of interactive TV services in a Browser-based environment</h2><h2 id="unofficial-draft-04-january-2012">Unofficial Draft 04 January 2012</h2><dl><dt>Editor:</dt><dd><span>Giuseppe Pascale</span>, <a href="http://www.opera.com/">Opera</a></dd>
+</dl><p class="copyright">This document is licensed under a <a class="subfoot" href="http://creativecommons.org/licenses/by/3.0/" rel="license">Creative Commons Attribution 3.0 License</a>.</p><hr></div>
+<div id="abstract" class="introductory section"><h2>Abstract</h2>
+
+</div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p>This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#background" class="tocxref"><span class="secno">1.1 </span>Background</a></li><li class="tocline"><a href="#audience" class="tocxref"><span class="secno">1.2 </span>Audience</a></li><li class="tocline"><a href="#scope" class="tocxref"><span class="secno">1.3 </span>Scope</a></li></ul></li><li class="tocline"><a href="#goals" class="tocxref"><span class="secno">2. </span>Goals</a><ul class="toc"><li class="tocline"><a href="#avoid-obsolesce" class="tocxref"><span class="secno">2.1 </span>Avoid obsolesce</a></li><li class="tocline"><a href="#avoid-fragmentation" class="tocxref"><span class="secno">2.2 </span>Avoid fragmentation</a></li><li class="tocline"><a href="#coordinate-deployments" class="tocxref"><span class="secno">2.3 </span>Coordinate deployments</a></li><li class="tocline"><a href="#provide-a-complete-application-environment" class="tocxref"><span class="secno">2.4 </span>Provide a complete application environment</a></li><li class="tocline"><a href="#do-not-reinvent-the-wheel" class="tocxref"><span class="secno">2.5 </span>Do not reinvent the wheel</a></li><li class="tocline"><a href="#a-tunable-meta-profile" class="tocxref"><span class="secno">2.6 </span>A tunable meta-profile</a></li></ul></li><li class="tocline"><a href="#overview" class="tocxref"><span class="secno">3. </span>Overview</a><ul class="toc"><li class="tocline"><a href="#system-architecture" class="tocxref"><span class="secno">3.1 </span>System Architecture</a></li><li class="tocline"><a href="#components-and-interfaces" class="tocxref"><span class="secno">3.2 </span>Components and interfaces</a></li></ul></li><li class="tocline"><a href="#application-model" class="tocxref"><span class="secno">4. </span>Application Model</a></li><li class="tocline"><a href="#user-experience" class="tocxref"><span class="secno">5. </span>User Experience</a><ul class="toc"><li class="tocline"><a href="#content-developers-guidelines" class="tocxref"><span class="secno">5.1 </span>Content Developers Guidelines</a></li><li class="tocline"><a href="#input-methods" class="tocxref"><span class="secno">5.2 </span>Input Methods</a><ul class="toc"><li class="tocline"><a href="#traditional-remote-controls" class="tocxref"><span class="secno">5.2.1 </span>Traditional Remote Controls</a></li><li class="tocline"><a href="#touch-screens" class="tocxref"><span class="secno">5.2.2 </span>Touch screens</a></li><li class="tocline"><a href="#mouse-and-keyboard" class="tocxref"><span class="secno">5.2.3 </span>Mouse and Keyboard</a></li><li class="tocline"><a href="#other-input-devices" class="tocxref"><span class="secno">5.2.4 </span>Other input devices</a></li></ul></li></ul></li><li class="tocline"><a href="#formats-and-protocols" class="tocxref"><span class="secno">6. </span>Formats and Protocols</a></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">B.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">B.2 </span>Informative references</a></li></ul></li></ul></div>
+
+<div class="informative section" id="introduction">
+<!--OddPage--><h2><span class="secno">1. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+
+ <div id="background" class="section">
+ <h3><span class="secno">1.1 </span>Background</h3>
+
+ In the past decades, many attempts have been made to create profiles suitable for use in a specific market and/or region, particularly in the TV space, by external organizations. These groups have created documents which are supersets, subsets or both of several W3C specifications. Often these documents have been developed without a direct involvement of relevant W3C working groups. Furthermore not always these different groups were aware of each other, leading to different profiles in different regions and markets. In some cases also extensions to web standards have been designed by different groups, leading to multiple incompatible solutions addressing the same use case.
+
+ By working on a common meta-profile within W3C it becomes easier to closely align external organizations with W3C and with each other. It also allows the W3C to move this profile forward on a regular basis to avoid obsolescence. While is not possible to provide a profile that cover all needs of different organizations and stakeholder, this documents tries to provide a meta-profile that try to keep at a minimum the variables involved in defining such profiles, making it a base that each external organization can use as a component.
+ </div>
+
+ <div id="audience" class="section">
+ <h3><span class="secno">1.2 </span>Audience</h3>
+ </div>
+
+ <div id="scope" class="section">
+ <h3><span class="secno">1.3 </span>Scope</h3>
+ </div>
+
+</div>
+
+<div class="informative section" id="goals">
+<!--OddPage--><h2><span class="secno">2. </span>Goals</h2><p><em>This section is non-normative.</em></p>
+This sections list the goals that have driven the work on this document.
+
+ <div id="avoid-obsolesce" class="section">
+ <h3><span class="secno">2.1 </span>Avoid obsolesce</h3>
+ In the past decades, many attempts have been made to create profiles suitable for use in a specific market and/or region, particularly in the TV space, by external organizations. These groups have created documents which are supersets, subsets or both of several W3C specifications. Often, these external documents become obsolete when the W3C improves the related specifications since the W3C has little or no knowledge of these external documents. By working on a common TV profile within W3C it becomes easier to closely align external organizations with W3C and with each other and allows the W3C to move this profile forward on a regular basis to avoid obsolescence.
+ </div>
+
+ <div id="avoid-fragmentation" class="section">
+ <h3><span class="secno">2.2 </span>Avoid fragmentation</h3>
+ Use of web technologies in different markets and regions to create interactive TV services is increasing. Different organizations and companies have have defined their own profiles of web technologies that can be used in a given ecosystem to author content. These profiles are supersets, subsets or both of several W3C specifications. The proliferation of such profiles is making challenging to write content that works well across devices. By working on a common TV profile within W3C it becomes easier to closely align ongoing efforts of web based TV services in order to avoid fragmentation.
+ </div>
+
+ <div id="coordinate-deployments" class="section">
+ <h3><span class="secno">2.3 </span>Coordinate deployments</h3>
+ The range of technologies available for web applications developers is so theoretically wide. In practice content developers have to fight with different levels of support of different specification by different devices. This is inevitable since each implementer necessarily need to make a choice on what to implement and when. While in some ecosystems is fine to leave to each implementer to choose his own roadmap, in other ecosystems there is a need for coordination in order to harmonize the development cycle of the different stakeholders (CE manufacturers, Content providers, Content Authors, etc.) and provide a good user experience.
+ </div>
+
+ <div id="provide-a-complete-application-environment" class="section">
+ <h3><span class="secno">2.4 </span>Provide a complete application environment</h3>
+ Many W3C specifications leave intentionally undefined some components that are essential to build a full application environment for interactive TV services. For example, the [<cite><a class="bibref" rel="biblioentry" href="#bib-HTML5">HTML5</a></cite>] specification rely on "relevant specifications" to define rules for processing and rendering data coming from a media stream via an in-band track. Other examples of "variables" that are not specified in [<cite><a class="bibref" rel="biblioentry" href="#bib-HTML5">HTML5</a></cite>] are supported video codecs or image formats. The same apply to other specifications. Furthermore to provide a complete application environment, different specifications needs to be combined into one product, increasing the number of options and hence the level of fragmentation. This document aims to combine together relevant specification to provide a complete environment that can be used by different organization as application environment for their interactive TV services.
+ </div>
+
+ <div id="do-not-reinvent-the-wheel" class="section">
+ <h3><span class="secno">2.5 </span>Do not reinvent the wheel</h3>
+ Some groups (both inside and outside W3C) have done an analysis of available web technologies in order to see if they were suitable to cover relevant use cases. Often what at a first look was identified as a gap in the web platform is resulted in actually being already supported reusing existing specifications. Since many use cases are common among different regions and organization, by making the result of such analysis available in one document the risk that different groups defines new technologies to cover areas that are already well covered by existing specification (hence causing fragmentation) is reduced.
+ </div>
+
+ <div id="a-tunable-meta-profile" class="section">
+ <h3><span class="secno">2.6 </span>A tunable meta-profile</h3>
+ A profile document is generally beneficial for the industry because it provides a common environment that all different stake holders can rely on with the ultimate goal of providing the best possible user experience. In doing this, several things need to be considered that sometimes goes beyond technical standard activities and is rather close to business model of stake holders. Furthermore, there are many different devices capable of presenting interactive TV services with different hardware capabilities that may also vary over time. Is then impossible to find a profile that suites all business models and devices, is possible to keep such differences at a minimum, identifying all the common parts in a meta profile that can be tuned as needed by other organizations.
+ </div>
+
+</div>
+
+<div id="overview" class="section">
+<!--OddPage--><h2><span class="secno">3. </span>Overview</h2>
+
+ <div id="system-architecture" class="section">
+ <h3><span class="secno">3.1 </span>System Architecture</h3>
+
+ </div>
+ <div id="components-and-interfaces" class="section">
+ <h3><span class="secno">3.2 </span>Components and interfaces</h3>
+ </div>
+</div>
+
+<div id="application-model" class="section">
+<!--OddPage--><h2><span class="secno">4. </span>Application Model</h2>
+
+</div>
+
+<div id="user-experience" class="section">
+ <!--OddPage--><h2><span class="secno">5. </span>User Experience</h2>
+
+ <div id="content-developers-guidelines" class="section">
+ <h3><span class="secno">5.1 </span>Content Developers Guidelines</h3>
+ </div>
+
+ <div id="input-methods" class="section">
+ <h3><span class="secno">5.2 </span>Input Methods</h3>
+ <div id="traditional-remote-controls" class="section">
+ <h4><span class="secno">5.2.1 </span>Traditional Remote Controls</h4>
+ </div>
+ <div id="touch-screens" class="section">
+ <h4><span class="secno">5.2.2 </span>Touch screens</h4>
+ </div>
+ <div id="mouse-and-keyboard" class="section">
+ <h4><span class="secno">5.2.3 </span>Mouse and Keyboard</h4>
+ </div>
+ <div id="other-input-devices" class="section">
+ <h4><span class="secno">5.2.4 </span>Other input devices</h4>
+ </div>
+ </div>
+
+</div>
+
+<div id="formats-and-protocols" class="section">
+ <!--OddPage--><h2><span class="secno">6. </span>Formats and Protocols</h2>
+</div>
+
+
+<div class="appendix section" id="acknowledgements">
+ <!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
+ <p> Thanks to ... for their contributions to this document</p>
+ <p> Thanks to participants of the following groups for their feedbacks: Web and TV Interest Group</p>
+</div>
+
+
+
+
+<div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">B. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">B.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">B.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-HTML5">[HTML5]</dt><dd>Ian Hickson; David Hyatt. <a href="http://www.w3.org/TR/html5"><cite>HTML5.</cite></a> 25 May 2011. W3C Working Draft. (Work in progress.) URL: <a href="http://www.w3.org/TR/html5">http://www.w3.org/TR/html5</a>
+</dd></dl></div></div></body></html>