OIPF 规范翻译（DAE）-----4.3 Application definition

4.3 Application definition
This section defines what is meant by the concept of a ‘DAE application’; which files and assets are considered to be part of a DAE application and how this relates to DAE application security and lifecycle.
A DAE application is an associated collection of documents (typically JavaScript, CSS and HTML or SVG documents)
from the same fully-qualified domain, unless specified differently in Section 5.1.1.3. It is accessed over TLS and
authenticated with an X509 certificate. Access to privileged capabilities can be requested through extensions to the X509 certificate (see section 10.1). Whilst the document is loaded within the browser, an additional browser object (the oipfApplicationManager object), defined in section 7.2.1 is present and accessible by the DAE application. The
ApplicationManager object provides access to the Application class defined in section 7.2.2 which provides
Javascript properties and methods that a DAE application possesses that exceed those of traditional “web pages”.
The difference between a DAE application and a traditional web page is the context within which it is loaded and
executes. For this reason, the definition and details of a DAE application focuses on the application execution
environment and the additional capabilities provided to DAE applications. The next subsections describe some of the
differences. Additional details about the DAE application lifecycle can be found in Section 5.1

 

4.3 应用程序定义

 

本节中将阐述“DAE应用程序”的概念；什么样的文件和对象（assets物品？）能够作为DAE应用程序的组成部分，以及与DAE应用安全及生命周期之间的关系。

 

一个DAE应用程序是一些相关文档（典型的如Javascript，CSS,HTML 或 SVG文档）的集合，这些文档来自同一个具备完全资格（估计是被授权之类的意义，译注）的主机（web服务器：译注），其中（我估计是文档规范中）要去除5.1.1.3中定义的不同点。其访问通过TLS（安全传输协议）并通过X509证书认证。访问特权功能通过使用扩展的X509证书（参照10.1节）。随着浏览器完成对文档的加载，DAE应用程序可以展现并获取到浏览器的扩展对象（oipfApplicationManager对象，7.2.1.节中定义）。ApplicationManager对象提供了对Application类的访问（在7.2.2节中定义），此类中提供了Javascript属性和方法供调用，DAE应用程序在一般网页上调用这些接口。

 

DAE应用程序和传统页面的不同之处是其中的内容是是加载完毕并可执行的。因此，DAE应用程序的定义和细节侧重于应用执行环境和DAE应用提供的扩展能力。

 

==================================================================================

 

LEFT: 0px">4.3.1 Similarities between applications and traditional web pages
Both applications and traditional web pages have an initial document, almost always written in HTML, which can include the contents of other documents. These included documents can have a variety of types, including Cascading Style Sheets (CSS), JavaScript, SVG, JPEG, PNG and GIF. A dynamic DOM, combined with XMLHttpRequest, permits AJAX-style changes to the current application or web page without necessarily replacing the entire document.

A dynamic DOM, combined with XMLHttpRequest, permits AJAX-style changes to the current application or web page without necessarily eplacing the entire document.

 

4.3.1 DAE应用和传统页面的相似性

二者都有一个起始文档（页面），而且几乎都是用HTML语言，同时其中可以包含其它类型文档的内容。这些包含的文档类型多样，可以是：层叠样式表（CSS），JavaScript，SVG, JPEG, PNG和GIF。

 

结合使用动态DOM技术和XMLHttpRequest,这种AJAX风格的方式可以动态修改页面或（DAE）应用程序的内容而无需重新载入（替换）整个页面。

 

 

==================================================================================

 

4.3.2 Differences between applications and traditional web pages 

An application is created and terminated in a different manner to a web page. For the case of application creation, it is 

this difference that indicates to the browser that a new application is being started, rather than the loading of a (new) web 

page. For the case of application destruction, the difference indicates the termination of an application, as opposed to the 

loading of new contents within the context of the current application. 

 

The application context includes information about the state of an application from the platform’s perspective – 

permissions, priority (importance: which to terminate first in the event of insufficient resources, for example) and similar 

information that spans all documents within an application during the lifetime of that application. 

An OITF SHALL support the execution of more than one application simultaneously. Applications MAY share the same 

screen estate in a defined and controlled fashion. This differs from multiple web pages, which are typically handled 

through different browser “windows” or “tabs” and may not share the same screen estate concurrently (although the 

details of this behaviour are often browser-dependent). This also differs from the use of frames, which, apart from 

iframes, do not support overlapping screen estate. Both foreground and background applications SHALL be supported 

simultaneously. 

 

Applications SHALL be recorded within a hierarchy of applications. Each object representing an application possesses 

an interface that provides access to methods and attributes that are uniquely available to applications. For example, 

facilities to create and destroy applications can be accessed through such methods 

 

 

4.3.2 应用程序和传统页面之间的差异

 

一个应用程序的创建和终止方式不同于一个web页面。对于应用程序的创建，这种差异体现为浏览器认为是一个应用程序的开始启动，而不是一个(新的)页面的正在被加载(loading).而对于应用程序的销毁，差异在于一个应用程序的终止执行，完全不同于加载新的内容替代当前应用程序中的内容。

应用程序的内容包含应用程序的状态信息，这些信息来源于平台的权限，优先级（重要性：决定在资源紧张时哪个首先被终止执行，例注）以及类似信息并且跨越整个文档存在于应用程序的整个生命周期内。

OITF应当支持超过一个应用同时运行。同时运行的所有应用程序共享同一个屏幕空间，并拥有统一的定义和控制方式（译注：同一个输入输出窗口）。这一点不同于多个web页面，多个web页通常通过不同的浏览器窗口或标签（多标签页面）实现，而且不会同时共享屏幕空间（但其具体细节依赖于不同

浏览器的行为实现）。同样的，这种方式也不同于使用框架（frames），除了使用iframe，这种方式不支持屏幕空间的前后重叠。无论是前景还是背景应用程序，都应该被同时支持。

所有的应用程序都被记录并构成一个层次结构（译注：应该是应用程序多能够被索引或者list之类，我不太懂翻译，能意会）。每一个对象都可以代表一个应用程序，这些对象拥有一个接口可以提供访问应用程序集合的属性和方法。例如：创建或者注销一个应用程序可以通过这种方法做到。【译注：我估计就是有一个application的列表，可以用一个对象指向其中每一个应用，然后对其执行相应的方法和属性调用】。

 

==================================================================================

4.3.3 The application tree 

Applications are organised into a tree structure. Using the createApplication() method as defined in Section 7.2.2.2, applications can be either be started as child nodes of the application or as a sibling of the application (added as a subtree of the parent of this application). The root node of an application tree is created upon loading an initial 

application URI or by creating a sibling of an application tree’s root node. An OITF MAY keep track of multiple 

application trees. Each of these individual application trees are connected to a hidden system root node maintained by the OITF that is not accessible by other applications. 

Applications created while the DAE environment is running (e.g. as a result of an external notification) that are not 

created through createApplication() SHALL be created as children of the hidden system root node. 

4.4.3 应用程序树

所有应用程序（们，哈哈）被组织到一个树形结构中。使用createApplication()方法（在7.2.2.2节中定义），应用程序可以作为一个子节点或者兄弟节点被创建（更多时候作为当前应用程序的子树存在）。应用程序的根节点在通过URI加载一个应用程序时被创建，或者在一个应用树根节点的兄弟节点创建时被创建。一个OITF可以包含多个应用程序树，这些独立的树都连接到OITF提供（维护）的一个隐含（隐藏）的根节点上，而不是由其它应用程序维护。

应用在DAE环境运行时就已经被创建（例如，由于一个外部通知），其创建不是通过createApplication()调用，而是做一系统隐藏根节点的子节点被创建。

==================================================================================

看个图片解解乏：

==================================================================================

4.3.4 The application display model 

Multiple applications SHALL be displayed on the OITF in one of the application visualization modes as defined in 

Section 4.4.6. 

The mode used SHALL be determined prior to initialisation of the DAE execution environment and shall persist until 

termination or re-initialization of the DAE execution environment.  The means by which this mode is chosen is outside 

the scope of this specification. 

Each application has an associated DOM Window object and a DOM Document object that represents the document that is currently loaded for that application. Even “windowless” applications that are never made visible have an associated DOM Window object. 

4.3.4 应用程序的现实模型

多个应用程序在OITF上的显示应该符合在4.4.6节中定义的应用显示模式之一。

模式应用时，应确保DAE执行环境已经初始化，并且确保DAE环境尚未退出或重新初始化。至于选择何种显示方式已经超出本规范的范围。

每个应用程序都有一个关联的DOM窗体对象和DOM文档对象，用以在当前加载的文档（页面）中代表应用本身。即使那种从来不显示的“没有窗体”的应用程序也拥有一个对应的DOM窗体对象。

==================================================================================

4.3.4.1 Manipulating an application’s DOM Window object 

Each application has an associated DOM Window object and a DOM Document object that represents the document that 

is currently loaded for that application. Even “windowless” applications that are never made visible have an associated 

DOM Window object. 

Standard DOM Window methods are used to resize, scroll, position and access the application document (see section 

4.4.6). Many browsers restrict the size or location of windows; these restrictions SHALL NOT be enforced for windows 

associated with applications within the browser area. Any area of the display available to DAE applications may be used 

by any application. Thus, ‘widget’-style applications can create a small window that contains only the application 

without needing to be concerned with any minimum size restrictions enforced by browsers. 

4.3.4.1 控制（Manipulating）应用程序的DOM窗体对象

每个应用程序都有一个关联的DOM窗体对象和DOM文档对象，用以在当前加载的文档（页面）中代表应用本身。即使那种从来不显示的“没有窗体”的应用程序也拥有一个对应的DOM窗体对象。

标准的DOM窗体方法可以完成其大小改变，滚动控制，定位（坐标）控制以及访问文档应用（请参看4.4.6节）。许多浏览器限制窗体的大小和定位

（location）；这些限制不应强制应用的关联窗体位于浏览器区域之内。DAE应用程序提供的任何显示区域，应该都能够被任何应用程序使用。由此看

来，“widget”（译注:即所谓的小浮动应用，yahoo首先引入）风格的应用程序可以创建一个小的窗体，其中只包含应用程序而无需考虑浏览器的最小

尺寸限制。

=====================================================================================

4.3.5 The security model 

Each application has a set of permissions to perform various privileged operations within the OITF. The permissions that 

are granted to an application are defined by the intersection of three permission sets: 

1.  The permissions requested by the application, using the mechanism defined in section 10. 

2.  The permissions supported by the OITF.  Some permissions may not be supported due to capability restrictions 

(e.g. the permission_pvr permission will never be granted on a receiver that does not support PVR capability).  

3.  The permissions that may be granted, as determined by user settings or configuration settings specified by the 

operator (e.g. blacklists or whitelists; see section 10 for more information).  This is a subset of (2), and may be 

different for different users. 

4.3.5 安全模型

每一个应用程序的权限设置为可以在OITF内执行各种特权操作。一个应用程序的权限取决于如下三个权限定义的交集：

1.  由应用程序要求的权限，遵循在第10节中定义的机制；

2.  由OITF支持并定义的权限，某些权限由于能力限制可能不会被支持（例如一个不支持PVR功能的设备永远无法支持一个PVR相关的权限定义）；

3.  对于不太重要的权限，可以依赖操作者的设置或配置决定（例如，黑名单或白名单，详见第十部分）。这事第二项的子集，并且可能随用户而不同；

=====================================================================================

4.3.6 Inheritance of permissions 

Applications created by other applications (e.g. using the methods described in sections 5.1.1.2 or 5.1.1.3) SHALL NOT 

inherit the permissions issued to the parent application. The permissions granted to the new application will be defined by 

the mechanism specified in section 10. 

When an application uses cross-document messaging as defined in [HTML5]  to communicate with another application, 

any action carried out in response to the message SHALL take place in the security context of the application to which 

the message was sent.  Applications SHOULD take care to ensure that privileged actions are only taken in response to 

messages from an appropriate source. 

4.3.6 权限的继承

一个应用程序被另一个所创建（使用5.1.1.2和5.1.1.3中定义的方法），但其不应继承其父节点（创建者）的权限定义。新创建程序的权限定义机制规范在第10节中定义。

每当一个应用程序使用HTML5中定义的跨文档消息和另一个应用程序通信，任何动作的回应信息都应该携带应用程序的安全内容并发送到命令发送者。应用程序应当注意携带特权操作的指令来自一个适当（被授权）的发送者（来源）。

=====================================================================================

4.3.7 Privileged application APIs 

The privilege model implemented with applications is based upon requiring access to the Application object 

representing an application in order to access the privileged functionality related to application lifecycle management and 

inter-application communication.  

Only web pages running as DAE applications (e.g. from a known provider and loaded via TLS) have access to an 

Application object (via the application/oipfApplicationManager object). 

4.3.7 应用程序保密（安全）相关API

应用程序实现授权安全模型的基础是对Application对象的访问（控制），表示应用程序访问一个特权函数（功能调用）并与应用生命周期管理器及跨程序通信协调运作。（译注：我觉得拗口，无法翻译，这种鸟语！）

只有当web页面已DAE应用程序的方式运行（例如：通过TLS从一个已知的提供者加载）才有机会访问一个Application对象（通过application/oipfApplicationManager对象）。

=====================================================================================

4.3.7.1 Compromising the security 

Since applications have access to Application objects, it is possible for applications to compromise the security of the framework by passing these objects to untrusted code. For example, an application could raise an event on an untrusted document and pass a reference to its Application object in the message. Any calls to methods on an Application object from pages not running as part of an application from the same provider SHALL throw an error as defined in section 10.1.1. 

4.3.7.1 安全机制的威胁

因为应用程序必须访问Application对象，那么就有可能使应用程序通过传入不可信的代码给application对象从而损害安全模型（框架）。例如：一个应用程序可以在一个不被信任的文档（页面）中发出一个事件，并通过引用一个Application对象将消息发送给它。任何来自页面的Application对象上的调用不能作为应用程序（同一个提供者）的一部分运行，而应该抛出一个错误（在10.1.1中定义）。

=====================================================================================