根据MIC调查，先进国家宽频网路环境健全，加上服务业者积极推展影视加值应用吸引用户，故预估2012年起至2014年网路视讯流量将超过有50%的成长空间。除了宽频网路串流的爆发外，台湾数位电视也积极的部署，有线宽频产业协会理事长简仁德表示，台湾有线电视头端数位化比例已经超过90%，整体数位化普及率仅约在7%上下，初步估计头端数位化投资总额超过50-60亿元。因此联网电视设备接收到经数位化处理后传输的数位电视讯号影音画面将更清晰，且具备电子节目表单与隐藏式字幕等功能，可接收宽频网路、IPTV、MOD、手机、STB、OTT Box等设备组成的应用平台，如：Google TV和Samsung Smart TV(Android)、Apple TV、Panasonic公布的新Viera Connect与Intel之BOXEE等平台，这样提供双向互动传输机制的设计，就是把电视讯号的控制权交给用户，促进了信息合理的流动，预期刺激更多用户行为，让整个联网电视平台应用体验更多元。

对Smart TV或OTT Box联网装置业者而言，选用何种平台作为开发的基准，无非是看中联网电视平台上App能带入丰富的内容资源。根据MIC2011年的统计，全球App软体商业市场规模仍持续的成长，且预计至2013年将超过有200亿美元的收入。此外，SPB TV也是一个联网电视的解决方案，也在3.0平台提供有手机版的TV app商店。因此widgets便是为了提供各种内容制造者或软体设计师，甚至系统整合商一个方便共通架构，参考图一的软体整合示意图，widgets是小型互动多媒体应用，其可用于桌上型电脑、行动电话与电视机、STB等设备。 widget的类型相当的多，典型的例子有日历、天气、游戏、便利贴、新闻等，不管是镶入网页的设计方式，或使用于单机版的应用，皆使用相同的方式制作widgets。从2006年开始W3C持续的更新相关的widgets家族规格，目前规范性规格有7组，包含widgets标准化的配置格式与封装格式(简称P&C)、定义储存偏好与存取widget封装内metadata的APIs规范(简称TWI)、定义widget封装进行数位签章时，使用到之自订XML签章语法与处理规格(简称DigSig)、当版本控制设计允许更新时，透过HTTP保持widget为最新版(Widget Updates over HTTP)、widget可透过URI认证资源要求/存取网页资料(简称WARP)、定义使用于widgets内的URI策略或使用于其他无法连网的网页技术(Widgets 1.0: URI Scheme)以及定义媒体功能CSS媒体询问相关的展现文件内容模式的规格(简称VMMF)。

《图一 概述联网电视设备之整体架构 (数据源：资策会绘制)》

Widget引擎组成介绍

目前已经有些领先市场的widget引擎(User Agent)参与W3C Widget的封装与配置测试一致性的吻合度，如：Owrandroid(Opera Widgets Runtime for Android)、Wookie(Apache)、Aplix、Opera、BorqsWRT1.0与Obigo，其中Opera 11.10 Beta和Apache Wookie 0.9与W3C widget的一致性最高，可使用JQuery javascript函式库捞进(mash up)所有公布于W3C网站上的测试案例，比对设计客制化的widget引擎与W3C widget标准的吻合度最高。图二显示一个widget引擎(User Agent)可分为五个基本组成技术，包含封装发布与布署、metedata配置、脚本存取连结、使用者介面和权限以及展现与行为逻辑，其中打星号的部分封装格式与数位签章、媒体类型、配置文件以及Widget的APIs在W3C的widget家族成员之规范性的规格内，都已经定义运作的方式，因此对开发者而言，widget引擎几乎就是仿造浏览器的行为，因此widget引擎也能绘制(render)网页，同时藉由ECMAScript的转译可与其他浏览器元件并入运作，widget为了给最终用户(end-user)带来单一互动应用感受，提供显示和/或更新本地数据或网页数据，因此包装法允许单一下载和安装到用户机(user's machine)、行动电话(mobile phone)、或上网设备(Internet-enabled device)。封装widget的优点就是可以在用户间共享widget包，而不需仰赖HTTP。

《图二 单机版的W3C widgets引擎整体架构 (数据源：W3C)》

封装widget包注意事项

所谓的widget包(参考图三)，就一个封装了所有该widget的相关资源，包含metadata描述文件(CSS, DOM等等)、配置文件、HTML/XML页面、图片和其他文件整体包裹成的压缩包，其封装格式可采用ZIP压缩的Deflate编码或未压缩仅封装的ZIP档案两种封装法，为了widget跨平台的互通性，这个ZIP档内相关档名的设计有些需要注意的事项，如同：须注意最长的关联档名长度建议是低于250字元，且为了避免档名字元组在ZIP打包后，跨不同作业系统执行时产生不一致的状况，建议采用Unicode编码的档名设计法(如：UTF-8编码)，还有此widget包内部的资料夹或个别档名在命名时，应避免使用到ZIP禁止字元，以及于档案或资料夹名称的最后一个字元也需要避免用到“.” U+002E FULL STOP和空白字元，因为有些档案系统在解压缩widget包时，会主动移除这些字元。

《图三 典型的widget包内档案分布状况 (数据源：W3C)》

Widget配置文件

每个widget包中包含一个metadata描述的XML配置文件，其档名为config.xml，档头必须标明使用xml的版本与采用的编码方式()，使用UTF-8的編碼格式可防止亂碼的產生，且在此組態文件檔案內，包含widget成員的宣告，以及widget的名稱")，使用UTF-8的编码格式可防止乱码的产生，且在此组态文件档案内，包含widget成员的宣告，以及widget的名称、描述、版权、作者等等内容，同时指定起始档(X)HTML/XML档案名称，预设起始档名为index.htm、index.html、índex.svg、index.xhtml与index.xht五种，也可使用content成员宣告加入客制的起始档，若要使用数位签章也可放置于config.xml内，此配置文件有11个成员，以widget成员作为根成员因此其包含相当多的子成员，name成员描述widget名称，description成员叙述用途，author成员标明此widget的作者资讯，license成员涵盖此widget配送的所有平台，icon成员是使用图像的方式呈现这个widget，content成员便是指名widget起始档案的服务为辅助程序机制(bootstrapping mechanism)，feature成员则是指要求进阶可用的功能如同API(例如：与camera镜头的连结、或使用LBS地理位置的API、或widget引擎内部自订的API等)，preference成员为宣告widget运行时可用的名称数值对(name-value pair)(例如：preference名称为api-key其对应数值则为该key使用到的f6d3a312f9d742机器码，还可指定存取属性)，以及param成员为宣告给某feature成员的子成员，还有span成员就是通用文本容器，为了国际化的目的而使用。以上所描述配置文件内使用到的11个成员与config.xml内文本节点(text node)间的亲子属性关系，且包含w3C网站上相关细部的属性定义，可参考图四与图五成员间父子状态图。

《图五 widget、icon、content、preference与feature成员与param成员间的关联性 (数据源：资策会绘制)》