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中定義）。
=====================================================================================
