You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1163 lines
48 KiB
1163 lines
48 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
|
|
<title>Component Extension (CX) API requirements Version 1.0</title>
|
|
<style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
dt.label { display: run-in; }
|
|
|
|
li p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
</style>
|
|
<link type="text/css" rel="stylesheet"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-NOTE.css" />
|
|
</head>
|
|
|
|
<body>
|
|
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C"
|
|
src="http://www.w3.org/Icons/w3c_home" /></a></p>
|
|
|
|
<h1>Component Extension (CX) API requirements Version 1.0</h1>
|
|
|
|
<h2>W3C Note 11 December 2001</h2>
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2001/NOTE-CX-20011211">http://www.w3.org/TR/2001/NOTE-CX-20011211</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/CX">http://www.w3.org/TR/CX</a></dd>
|
|
<dt>Editors:</dt>
|
|
<dd>Angel Diaz, IBM</dd>
|
|
<dd>Jon Ferraiolo, Adobe</dd>
|
|
<dd>Stein Kulseth, Opera</dd>
|
|
<dd>Philippe Le Hégaret, W3C</dd>
|
|
<dd>Chris Lilley, W3C</dd>
|
|
<dd>Charles McCathieNevile, W3C</dd>
|
|
<dd>Tapas Roy, Openwave</dd>
|
|
<dd>Ray Whitmer, Netscape/AOL</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>
|
|
©2001 <a href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
|
|
href="http://www.lcs.mit.edu/"><abbr
|
|
title="Massachusetts Institute of Technology">MIT</abbr></a>, <a
|
|
href="http://www.inria.fr/"><abbr
|
|
title="Institut National de Recherche en Informatique et Automatique"
|
|
xml:lang="fr" lang="fr">INRIA</abbr></a>, <a
|
|
href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">liability</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">trademark</a>,
|
|
<a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">document
|
|
use</a>, and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">software
|
|
licensing</a> rules apply.</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div>
|
|
<h2><a name="abstract" id="abstract">Abstract</a></h2>
|
|
|
|
<p>From the early days of the World Wide Web, Web Agents had been extended to
|
|
support more types of contents. The recent developments of XML and the
|
|
possibility to mix mupltiple XML Namespaces in the document reiterated the
|
|
need to extend implementations and relaying on add-on softwares to accomplish
|
|
tasks not supported by default in the implementation. In other words, we have
|
|
several XML languages to represent different parts of Web pages (XHTML, SVG,
|
|
MathML, XForms, etc.), we now need a well defined mechanism that allow
|
|
different specialized tools to work together and handled these compound
|
|
documents.</p>
|
|
|
|
<p>This W3C Note contains a non-exhaustive list of requirements to work on a
|
|
<a title="" href="#cx">Component Extension</a> API. The goal of this <a
|
|
title="" href="#api">API</a> is to extend the ability of a Web application.
|
|
Note that the Web application can be either on the server side or on a client
|
|
side, and does not automatically implies interaction with a user or having a
|
|
Web browser.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2><a name="status" id="status">Status of this Document</a></h2>
|
|
|
|
<p>This document is an early draft resulting from the HyperText Coordination
|
|
Group face to face meeting to discuss standardization of Plug-in and Active
|
|
Component Architecture for the Web. It is anticipated that this will be
|
|
published as a W3C note as soon as it has reached an appropriate state of
|
|
maturity.</p>
|
|
|
|
<p>This document is a <a
|
|
href="http://www.w3.org/Consortium/Process-20010719/tr.html#Notes">Note</a>
|
|
made available by the W3C for discussion only. Publication of this Note by
|
|
W3C indicates no endorsement by W3C or the W3C Team, or any W3C Members.
|
|
There is no commitment by W3C to invest additional resources in topics
|
|
addressed by this Note.</p>
|
|
|
|
<p>Comments on this document are invited and are to be sent to the public
|
|
mailing list <a
|
|
href="mailto:www-component-extension@w3.org">www-component-extension@w3.org</a>.
|
|
An archive is available at <a
|
|
href="http://lists.w3.org/Archives/Public/www-component-extension/">http://lists.w3.org/Archives/Public/www-component-extension/</a>.</p>
|
|
|
|
<p><a href="http://www.w3.org/TR/">W3C Technical reports</a> are published
|
|
online at http://www.w3.org/TR.</p>
|
|
</div>
|
|
|
|
<div class="toc">
|
|
<h2><a name="contents" id="contents">Table of Contents</a></h2>
|
|
|
|
<p class="toc">1 <a href="#intro">Requirements</a><br />
|
|
1.1 <a href="#N108">Formatting</a><br />
|
|
1.1.1 <a
|
|
href="#N115">baseline and linehight</a><br />
|
|
1.1.2 <a
|
|
href="#size_rect">linebreak, size and rectangle negotiation, multiple
|
|
rectangles</a><br />
|
|
1.1.3 <a href="#N130">DOM
|
|
Views and Formatting</a><br />
|
|
1.2 <a href="#N140">Rendering</a><br />
|
|
1.2.1 <a
|
|
href="#N146">freeze/unfreeze</a><br />
|
|
1.2.2 <a
|
|
href="#N175">z-order/painting</a><br />
|
|
1.2.2.1
|
|
<a href="#N186">clipping</a><br />
|
|
1.2.3 <a href="#N194">sharing
|
|
colormap</a><br />
|
|
1.2.4 <a href="#N1A2">sharing
|
|
fonts</a><br />
|
|
1.2.5 <a href="#N1CA">colors
|
|
(accessibility issues)</a><br />
|
|
1.2.6 <a href="#N1D1">Device
|
|
dependent drawing</a><br />
|
|
1.2.7 <a href="#N1DF">forcing
|
|
redraws, invalidate rectangles, invalidate region</a><br />
|
|
1.2.8 <a
|
|
href="#N206">window-less plug-in</a><br />
|
|
1.3 <a href="#style">Style</a><br />
|
|
1.3.1 <a href="#DOMCSS">DOM
|
|
CSS</a><br />
|
|
1.3.1.1
|
|
<a href="#N23B">specified values</a><br />
|
|
1.3.1.2
|
|
<a href="#computed">computed values</a><br />
|
|
1.3.2 <a
|
|
href="#actualCSS">actual values</a><br />
|
|
1.3.3 <a
|
|
href="#generic_style">Generic Styler</a><br />
|
|
1.3.4 <a
|
|
href="#local_style">Local Styler</a><br />
|
|
1.3.5 <a
|
|
href="#mobile_profiles">Mobile profiles</a><br />
|
|
1.4 <a href="#error">Error handling</a><br />
|
|
1.5 <a href="#events">Events</a><br />
|
|
1.6 <a href="#DOMCore">DOM Core tree</a><br />
|
|
1.7 <a href="#starting">Starting point</a><br />
|
|
1.8 <a href="#conn_script">Connecting with
|
|
outside/scripting</a><br />
|
|
1.9 <a href="#nesting">Nesting/reetrance</a><br />
|
|
1.10 <a href="#abstraction">Abstraction level</a><br
|
|
/>
|
|
1.11 <a href="#timeline">timeline</a><br />
|
|
1.12 <a href="#network">network/HTTP</a><br />
|
|
1.13 <a href="#editing">Editing</a><br />
|
|
1.13.1 <a
|
|
href="#N50A">Editing mode</a><br />
|
|
1.14 <a
|
|
href="#associations">associations/registrations/negociations</a><br />
|
|
1.15 <a href="#accessibility">Accessibility</a><br />
|
|
1.16 <a href="#versioning">Versioning</a><br />
|
|
1.17 <a href="#storage">storage/persistence</a><br />
|
|
1.18 <a href="#memory">Memory management</a><br />
|
|
1.19 <a href="#N635">Security</a><br />
|
|
</p>
|
|
|
|
<h3>Appendices</h3>
|
|
|
|
<p class="toc">A <a href="#N642">Glossary</a><br />
|
|
B <a href="#references">References</a><br />
|
|
C <a href="#N79B">Contributors</a><br />
|
|
</p>
|
|
</div>
|
|
<hr />
|
|
|
|
<div class="body">
|
|
|
|
<div class="div1">
|
|
<h2><a name="intro" id="intro"></a>1 Requirements</h2>
|
|
|
|
<p>This document contains a description of the <a title=""
|
|
href="#cx">Component Extension</a> requirements established during the
|
|
HyperText CG meeting in August 2001. It classifies the <a title=""
|
|
href="#api">Application Programming Interface (API)</a> requirements in 3
|
|
categories:</p>
|
|
<dl>
|
|
<dt class="label">[1]</dt>
|
|
<dd><p>The requirement must be addressed by the Component Extension
|
|
API.</p>
|
|
</dd>
|
|
<dt class="label">[2]</dt>
|
|
<dd><p>The requirement may be addressed by the Component Extension
|
|
API.</p>
|
|
</dd>
|
|
<dt class="label">[3]</dt>
|
|
<dd><p>The requirement is declared out of the scope of the Component
|
|
Extension API. It might become in its scope in future versions.</p>
|
|
</dd>
|
|
</dl>
|
|
|
|
<p>The description of a Component Extension must be in terms of content that
|
|
is handled, not in terms of a specific piece of software. For example, it is
|
|
appropriate to request a Component Extension that handles SVG <a
|
|
href="#SVG1">[SVG 1.0]</a>, including some set of functionalities (for
|
|
example identified using the SMIL required functionalities mechanism for the
|
|
switch element, or the SVG equivalent).</p>
|
|
|
|
<p>The list of requirements provided in this document is not exhaustive and
|
|
only reflects the requirements from the HyperText CG meeting.</p>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="N108" id="N108"></a>1.1 Formatting [1]</h3>
|
|
|
|
<p>The <a title="" href="#host">Host implementation</a> must provide a
|
|
mechanism for an embedded object to request a region or set of regions for
|
|
displaying content. The formatting interface should be independent of
|
|
platform specific constraints.</p>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N115" id="N115"></a>1.1.1 baseline and
|
|
linehight [1]</h4>
|
|
|
|
<p>The Host implementation and Component Extension need to coordinate the
|
|
linehight and the baseline.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="size_rect" id="size_rect"></a>1.1.2 linebreak,
|
|
size and rectangle negotiation, multiple rectangles [1]</h4>
|
|
|
|
<p>The Host shall provide means to determine the maximum size of the
|
|
rectangle into which the embedded object may render. Conceptually, the size
|
|
of this page may be unconstrained in both dimensions given scrolling. In
|
|
practice, the Host must somehow constrain this in at least one dimension.</p>
|
|
|
|
<p>For example, the Host may indicate that this rectangle is scrollable in
|
|
the line-stacking direction. It must fix the other dimension. Typically, it
|
|
would report the current width of its renderable area.</p>
|
|
|
|
<p>The embedded object must be permitted to negotiate rectangles and break
|
|
into smaller areas across lines if need be.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority2"><a name="N130" id="N130"></a>1.1.3 DOM Views and
|
|
Formatting [2]</h4>
|
|
|
|
<p>The <a href="#DOM3VF">[DOM Level 3 Views and Formatting]</a> should be
|
|
considered by the Component Extension API.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="N140" id="N140"></a>1.2 Rendering [1]</h3>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N146" id="N146"></a>1.2.1 freeze/unfreeze
|
|
[1]</h4>
|
|
|
|
<p>A <a title="" href="#cx">Component Extension</a> may wish to suspend
|
|
rendering momentarily while for example a succession of changes are made to
|
|
the structure, or the structure is made temporarily invalid, or for some
|
|
other reason whereby the intermediate state of the document is no to be
|
|
displayed. Examples of such methods:</p>
|
|
<dl>
|
|
<dt class="label">SVG DOM: SVGSVGelement</dt>
|
|
<dd>
|
|
<table summary="Example" width="100%" bgcolor="#99ffff" border="1"
|
|
cellpadding="5" class="eg">
|
|
<tbody>
|
|
<tr>
|
|
<td><pre> unsigned long suspendRedraw(in unsigned long max_wait_milliseconds);
|
|
void unsuspendRedraw(in unsigned long suspend_handle_id)
|
|
raises(DOMException);
|
|
void unsuspendRedrawAll();
|
|
void forceRedraw();
|
|
void pauseAnimations();
|
|
void unpauseAnimations();
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>See also section 5.11 in <a href="#">[SVG10]</a>.</p>
|
|
</dd>
|
|
<dt class="label">Openwave plugin API</dt>
|
|
<dd><p>PluginSuspend and PluginResume methods.</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N175" id="N175"></a>1.2.2 z-order/painting
|
|
[1]</h4>
|
|
|
|
<p>It should be possible for content which is rendered by <a title=""
|
|
href="#cx">Component Extensions</a> to take its correct place in the z-order
|
|
of the entire document - it can be above other content such as backgrounds,
|
|
which show through transparent areas, and other content later in the document
|
|
or with higher z-order should be able to partially overlap content rendered
|
|
by the <a title="" href="#cx">Component Extension</a>.</p>
|
|
|
|
<div class="div4">
|
|
<h5 class="priority1"><a name="N186" id="N186"></a>1.2.2.1 clipping [1]</h5>
|
|
|
|
<p><b>Clipping</b>, which addresses removal of parts of display elements that
|
|
lie outside of a given boundary, must be addrssed by the Component
|
|
Extension.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority2"><a name="N194" id="N194"></a>1.2.3 sharing colormap
|
|
[2]</h4>
|
|
|
|
<p>Implementations which require a colormap will need to allow the <a
|
|
title="" href="#cx">Component Extension</a> to request the allocation of
|
|
colors in the colormap and to find out what colors are already in the
|
|
colormap, and to be notified if the color associated with a particular color
|
|
index has changed.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority2"><a name="N1A2" id="N1A2"></a>1.2.4 sharing fonts
|
|
[2]</h4>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> should have access to
|
|
system fonts and their properties. The Host implementation provide means for
|
|
querying metrics of the current font. Metrics of interest could be a subset
|
|
of those provided by <a href="#opentype">[OpenType]</a>. The Host
|
|
implementation should provide methods for determining glyph bounding boxes,
|
|
baselines, and nominal font height. It should also provide an indication
|
|
whether a given character maps to a glyph in that font. The <a title=""
|
|
href="#cx">Component Extension</a> should be able to find out about
|
|
downloadable fonts that other content on the same page has made available,
|
|
and itself to make available fonts that it has downloaded. The font
|
|
properties in use on the parent of the element whose content is being
|
|
rendered by the <a title="" href="#cx">Component Extension</a> should be made
|
|
available by inheritance over the <a title="" href="#cx">Component
|
|
Extension</a> interface so that the same fonts can be used by the <a title=""
|
|
href="#cx">Component Extension</a>.</p>
|
|
|
|
<p>Accessibility information about preferred font sizes should be passed
|
|
across the <a title="" href="#cx">Component Extension</a> interface.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N1CA" id="N1CA"></a>1.2.5 colors
|
|
(accessibility issues) [1]</h4>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N1D1" id="N1D1"></a>1.2.6 Device dependent
|
|
drawing [1]</h4>
|
|
|
|
<p><a title="" href="#cx">Component Extension</a> API should provide a
|
|
platform dependent (e.g. XWindow Graphic Context, Microsoft Device Context)
|
|
method for gathering device dependent information for formatting and drawing
|
|
into each of the rectangles (e.g. for optimisation of drawing, such as
|
|
window, device context, fonts). However this must not preclude the ability to
|
|
use device independent methods, and the specification should recommend that
|
|
these are available as a fallback.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N1DF" id="N1DF"></a>1.2.7 forcing redraws,
|
|
invalidate rectangles, invalidate region [1]</h4>
|
|
|
|
<p>In the Component Extension-does-compositing model with direct screen
|
|
drawing, a <a title="" href="#cx">Component Extension</a> might damage
|
|
content rendered by something else. This is like the situation in windowing
|
|
systems where a window is iconised and (portions of) other windows that are
|
|
now uncovered have to be told to redraw.</p>
|
|
|
|
<p>The container-does-compositing model, with rendering being an offscreen
|
|
RGBA pixmap, does not have this problem and need not tell its parents or
|
|
other <a title="" href="#cx">Component Extension</a>s to redraw. Moving or
|
|
update of a <a title="" href="#cx">Component Extension</a> merely requires
|
|
re-composition of the current stack of offscreens without the need for a
|
|
forced redraw, though this can be limited to a particular invalidated
|
|
region.</p>
|
|
|
|
<div class="issue">
|
|
<p class="prefix"><a name="rectangle-region-1"
|
|
id="rectangle-region-1"></a><b>Issue (rectangle-region-1):</b></p>
|
|
|
|
<p>These descriptions narrowly miss actually listing a requirement. Make it
|
|
simpler.</p>
|
|
</div>
|
|
|
|
<p>See also <a href="#Netscape3">[Netscape Plug-ins]</a>.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N206" id="N206"></a>1.2.8 window-less plug-in
|
|
[1]</h4>
|
|
|
|
<p><a title="" href="#cx">Component Extension</a> which do not draw at all
|
|
should be addressed by the <a title="" href="#cx">Component Extension</a>
|
|
API.</p>
|
|
|
|
<p>See also <a href="#Netscape3">[Netscape Plug-ins]</a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="style" id="style"></a>1.3 Style [1]</h3>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="DOMCSS" id="DOMCSS"></a>1.3.1 DOM CSS [1]</h4>
|
|
|
|
<p>This section describes the relation between the <a title=""
|
|
href="#cx">Component Extension</a> API and the Document Object Model (DOM)
|
|
Level 2 CSS specification <a href="#DOM2Style">[DOM Level 2 Style Sheets and
|
|
CSS]</a>.</p>
|
|
|
|
<div class="div4">
|
|
<h5 class="priority3"><a name="N23B" id="N23B"></a>1.3.1.1 specified values
|
|
[3]</h5>
|
|
|
|
<p>Unlike the DOM Level 2 CSS specification <a href="#DOM2Style">[DOM Level 2
|
|
Style Sheets and CSS]</a>, this note does not require access to the specified
|
|
CSS values in the style sheets.</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5 class="priority1"><a name="computed" id="computed"></a>1.3.1.2 computed
|
|
values [1]</h5>
|
|
|
|
<p>If the <a title="" href="#host">Host implementation</a> provides a DOM
|
|
tree to the Component Extension and a CSS Style engine, the <a title=""
|
|
href="#cx">Component Extension</a> API must have access to the computed CSS
|
|
values of its nearest DOM Node ancestor (its parentNode) using the DOM Level
|
|
2 CSS <a href="#DOM2Style">[DOM Level 2 Style Sheets and CSS]</a> ViewCSS
|
|
interface. Depending on the CSS Style engine, the Host Implementation may
|
|
also provide a fully decorated DOM tree for the content addressed by the <a
|
|
title="" href="#cx">Component Extension</a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority3"><a name="actualCSS" id="actualCSS"></a>1.3.2 actual
|
|
values [3]</h4>
|
|
|
|
<p>Actual CSS values, as defined in the CSS specification <a
|
|
href="#CSS2">[CSS Level 2]</a>, will not be addressed by the <a title=""
|
|
href="#cx">Component Extension</a> API.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="generic_style" id="generic_style"></a>1.3.3
|
|
Generic Styler [1]</h4>
|
|
|
|
<p>The <a title="" href="#host">Host implementation</a> should contain a
|
|
Style engine to handle general properties and to provide extension mechanism
|
|
in order to support other properties. This Generic Styler engine has the
|
|
responsibility of decorating the DOM tree with the computed values (see also
|
|
<a href="#computed"><b>1.3.1.2 computed values</b></a>).</p>
|
|
|
|
<p>Languages, such as CSS, have mechanism to extend the set of style
|
|
properties used in the application. As an example, SVG 1.0 <a
|
|
href="#SVG1">[SVG 1.0]</a> reused some of the properties listed in the CSS 2
|
|
specification <a href="#CSS2">[CSS Level 2]</a> and adds new ones. It is
|
|
expected that the Generic Styler of the <a title="" href="#host">Host
|
|
implementation</a> supports a specific set of properties and some general
|
|
style properties such as color, background or fonts are required to be
|
|
supported. [<a title="foreign style property" name="foreign"
|
|
id="foreign">Definition</a>: A <b>foreign style property</b> is a style
|
|
property that is not recognized internally by the Generic Styler.] The
|
|
Generic Styler does not know its default value, or if the value could be
|
|
inherited or not. The Generic Styler is expected to support <a
|
|
title="foreign style property" href="#foreign">foreign style
|
|
properties</a>.</p>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> should declare
|
|
information on style properties it uses that may be foreign to the Generic
|
|
Styler such as parse, default values, inheritance, ... The Styler is
|
|
responsible for maintaining the information and dealing with duplicate
|
|
declarations between Component Extensions. A Component Extension remove style
|
|
properties or values associated with the style properties. In other words,
|
|
the set of style properties stored by the Generic Styler is the union of the
|
|
set of style properties supported by the <a title="" href="#host">Host
|
|
implementation</a> and its <a title="" href="#cx">Component Extension</a>s.
|
|
If a computed value is not recognized, the Generic Styler can:</p>
|
|
<ul>
|
|
<li><p>use a default value</p>
|
|
</li>
|
|
<li><p>like for colors, always make the computed value have two parts</p>
|
|
<ol>
|
|
<li><p>a value in first set of values</p>
|
|
</li>
|
|
<li><p>a possible extended value</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
<li><p>have extended value + callback</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<div class="issue">
|
|
<p class="prefix"><a name="generic-style-engine-1"
|
|
id="generic-style-engine-1"></a><b>Issue (generic-style-engine-1):</b></p>
|
|
|
|
<p>What to do about style sheets when it is not known what Component
|
|
Extension will be loaded?</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority2"><a name="local_style" id="local_style"></a>1.3.4 Local
|
|
Styler [2]</h4>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> can also embedded its
|
|
own local Style engine. In this case, the Component Extension does not need
|
|
to declare or get the computed values of the style properties in a DOM tree.
|
|
This model has the advantage to not assume a DOM API between the <a title=""
|
|
href="#host">Host implementation</a> and the <a title="" href="#cx">Component
|
|
Extension</a>, and only applies to the root node of <a title=""
|
|
href="#cx">Component Extension</a> (<code>svg:svg</code>,
|
|
<code>math:math</code>, ...). The local Style engine needs to provide:</p>
|
|
<ul>
|
|
<li><p>access to style sheets.</p>
|
|
</li>
|
|
<li><p>access to containing DOM tree (optional).</p>
|
|
</li>
|
|
<li class="priority1"><p>access to the <code>[parent]</code> information
|
|
item in order to get the computed values of the style properties:
|
|
<code>propname -> value</code></p>
|
|
[1]</li>
|
|
<li class="priority1"><p>access to style properties information:
|
|
<code>propname -> inherit/initial value</code>.</p>
|
|
[1]</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="mobile_profiles"
|
|
id="mobile_profiles"></a>1.3.5 Mobile profiles [1]</h4>
|
|
|
|
<p>Mobile profiles are always required to be supported by the Host
|
|
implementation and its <a title="" href="#cx">Component Extensions</a>.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority2"><a name="error" id="error"></a>1.4 Error handling
|
|
[2]</h3>
|
|
|
|
<p>An error handling mechanism should be provided by the Host implementation
|
|
to the <a title="" href="#cx">Component Extension</a> in a future revision of
|
|
the <a title="" href="#cx">Component Extension</a> API. This mechanism may be
|
|
based on, or inspired from, the error handling mechanism provided by the DOM
|
|
Level 3 Core specification <a href="#DOM3Core">[DOM Level 3 Core]</a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="events" id="events"></a>1.5 Events [1]</h3>
|
|
|
|
<p>There must be a way to pass events from the <a title="" href="#host">Host
|
|
implementation</a> to the <a title="" href="#cx">Component Extension</a> and
|
|
from the <a title="" href="#cx">Component Extension</a> to the Host
|
|
implementation. If the <a title="" href="#host">Host implementation</a>
|
|
provides a DOM tree to the component extension and contains an event
|
|
mechanism, the Component Extension API must support the DOM Level 2 Events
|
|
specification. User Interface events, such as window events or system events
|
|
(reload, URI notify events), may be addressed.</p>
|
|
|
|
<p>Namespace-bound events are events whose propagation is limited to elements
|
|
namespace boundaries, i.e. it propagates until it reaches an element who does
|
|
not use its ancestor's namespace name. Namespace bound events are out of
|
|
scope.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="DOMCore" id="DOMCore"></a>1.6 DOM Core tree
|
|
[1]</h3>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> API must provide
|
|
programmatic read-only access to HTML and XML content by conforming to the
|
|
following modules of the W3C Document Object Model Level 2 Core Specification
|
|
<a href="#DOM2Core">[DOM Level 2 Core]</a> and exporting the interfaces they
|
|
define:</p>
|
|
<ul>
|
|
<li><p>the Core module for HTML</p>
|
|
</li>
|
|
<li><p>the Core and XML modules for XML.</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="starting" id="starting"></a>1.7 Starting point
|
|
[1]</h3>
|
|
|
|
<p>Features of the existing Netscape Plugin API <a
|
|
href="#Netscape3">[Netscape Plug-ins]</a> should considered as a starting
|
|
point with implementation experience for features of the <a title=""
|
|
href="#cx">Component Extension</a> API, which may be modified, replaced, or
|
|
eliminated as required to address problems and requirements.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="conn_script" id="conn_script"></a>1.8
|
|
Connecting with outside/scripting [1]</h3>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> will call a <a title=""
|
|
href="#host">Host implementation</a> function to request a connection to one
|
|
of its features.</p>
|
|
|
|
<p>This feature may be a generic functionality (eg. "copy/paste", whether
|
|
this is selected by button, menu item, keyboard shortcut, drag-drop, or ...)
|
|
or a specific <a title="" href="#host">Host implementation</a> chrome (eg.
|
|
toolbar, button, status bar ... ).</p>
|
|
|
|
<p>The request can be to output data through the feature (eg. status bar,
|
|
title bar, alert, ...), to subscribe to events generated from a browser
|
|
control, or to add a control to the chrome (eg. toolbar, menubar, menu
|
|
...)</p>
|
|
|
|
<p>The <a title="" href="#host">Host implementation</a> should return a value
|
|
indicating whether it allows the connection or not.</p>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> API should define how
|
|
the features are selected, and specify a minimal list of connections that the
|
|
browser *should* allow if it does have the requested feature, so that the <a
|
|
title="" href="#cx">Component Extension</a> can reasonably expect such a
|
|
connection request to be granted.</p>
|
|
|
|
<p>Subscribed-to events can be passed to the <a title="" href="#cx">Component
|
|
Extension</a> using the normal event-passing mechanism (see <a
|
|
href="#events"><b>1.5 Events</b></a>). If the connection needs to pass large
|
|
amounts of data, the <a title="" href="#cx">Component Extension</a>'s stream
|
|
APIs should be used.</p>
|
|
<ul>
|
|
<li><p class="priority1">chrome <em>[1]</em></p>
|
|
<ul>
|
|
<li><p>adding new items/removing new items</p>
|
|
</li>
|
|
<li><p>"right-click drop down menu"/main menu bar</p>
|
|
</li>
|
|
<li><p>status line</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><p>copy/paste</p>
|
|
</li>
|
|
<li><p>find</p>
|
|
</li>
|
|
<li><p>drag/drop</p>
|
|
</li>
|
|
<li><p>focus</p>
|
|
</li>
|
|
<li><p class="priority1">alert <em>[1]</em></p>
|
|
</li>
|
|
<li><p>query user agents capabilities?</p>
|
|
</li>
|
|
<li><p>cross plug-in streams</p>
|
|
</li>
|
|
<li><p class="priority2">properties <em>[2]</em></p>
|
|
<ul>
|
|
<li><p>properties dialog</p>
|
|
</li>
|
|
<li><p>system properties: hostname, IP, ...</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="nesting" id="nesting"></a>1.9
|
|
Nesting/reetrance [1]</h3>
|
|
|
|
<p>It must be possible for a <a title="" href="#cx">Component Extension</a>
|
|
to discover, where available, and integrate the formatting and rendering of
|
|
externally supported content types inserted into the <a title=""
|
|
href="#cx">Component Extension</a> DOM Node's subhierarchy that are not
|
|
internally supported by the <a title="" href="#cx">Component
|
|
Extension</a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="abstraction" id="abstraction"></a>1.10
|
|
Abstraction level [1]</h3>
|
|
|
|
<p>Much like the W3C DOM IDL descriptions and language bindings, the
|
|
Component Extension API must be described independent of programming
|
|
language, operating system and platform.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority2"><a name="timeline" id="timeline"></a>1.11 timeline
|
|
[2]</h3>
|
|
|
|
<p>SMIL 2.0 <a href="#SMIL20">[SMIL 2.0]</a> is a specification for
|
|
synchronized multimedia and SMIL Animation <a href="#SMILAnimation">[SMIL
|
|
Animation]</a> is a specification for how the timing and animation aspects of
|
|
SMIL 2.0 can be integrated into other languages, such as SVG (see chapter 19
|
|
in <a href="#">[SVG10]</a>).</p>
|
|
|
|
<p>If the <a title="" href="#host">Host implementation</a> supports
|
|
synchronized playing of media such as audio, video or animations, then the
|
|
Host implementation must support the ability for time-based <a title=""
|
|
href="#cx">Component Extensions</a> to play media on a portion of a Host
|
|
canvas, and the Host-played media and the Component Extension-played media
|
|
must be synchronized. The API for achieving this synchronization must be rich
|
|
enough to permit accurate implementation of the 'syncBehavior' and
|
|
'syncTolerance' attributes defined in the section 10.3.1 in <a
|
|
href="#SMIL20">[SMIL 2.0]</a>.</p>
|
|
|
|
<p>SMIL 2.0 and SMIL Animation allow content to be started and stopped via
|
|
interactivity, such as User Interface events (e.g., mouse and keyboard).
|
|
Host-supplied event propagation APIs must be such that time-based <a title=""
|
|
href="#cx">Component Extensions</a> can implement the interactivity
|
|
capabilities defined in the section 10.3.1, "Basic time support", in <a
|
|
href="#SMIL20">[SMIL 2.0]</a>.</p>
|
|
|
|
<p>If the <a title="" href="#host">Host implementation</a> supports streaming
|
|
media, then the <a title="" href="#host">Host implementation</a> must supply
|
|
APIs that allow <a title="" href="#cx">Component Extensions</a> to receive
|
|
streaming content.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="network" id="network"></a>1.12 network/HTTP
|
|
[1]</h3>
|
|
|
|
<p>Networking Support will include an API to request the data from a URI
|
|
reference.</p>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> will call a <a title=""
|
|
href="#host">Host implementation</a> function and pass the URI reference, any
|
|
additional headers (for example, in the case of HTTP, maybe an additional
|
|
accept type), the method (in case of HTTP, GET, PUT, POST or HEAD) and a
|
|
pointer to a notify data. The <a title="" href="#cx">Component Extension</a>
|
|
may tell the <a title="" href="#host">Host implementation</a> to use the
|
|
cache or to override it.</p>
|
|
|
|
<p>When the request is complete, the <a title="" href="#host">Host
|
|
implementation</a> will call the <a title="" href="#cx">Component
|
|
Extension</a>'s notify function, and pass the data to the <a title=""
|
|
href="#cx">Component Extension</a> using the <a title="" href="#cx">Component
|
|
Extension</a>'s stream APIs.</p>
|
|
|
|
<p>Example:</p>
|
|
|
|
<table summary="Example" width="100%" bgcolor="#99ffff" border="1"
|
|
cellpadding="5" class="eg">
|
|
<tbody>
|
|
<tr>
|
|
<td><pre> kError HostURIRequest(kURIMethod method,
|
|
const char *uri,
|
|
const char *headers,
|
|
const char *entity,
|
|
unsigned long entitySize,
|
|
void* notifyData,
|
|
boolean useCache);
|
|
void CXURINotify(const char *uri,
|
|
kStatus status,
|
|
void* notifyData);
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<div class="issue">
|
|
<p class="prefix"><a name="networking-1" id="networking-1"></a><b>Issue
|
|
(networking-1):</b></p>
|
|
|
|
<p>In the Netscape model <a href="#Netscape3">[Netscape Plug-ins]</a>, the
|
|
data corresponding to a network request are sent to the <a title=""
|
|
href="#cx">Component Extension</a> by the <a title="" href="#host">Host
|
|
implementation</a> by creating a stream: it is a callback mechanism.</p>
|
|
|
|
<p>Should we reused this mechanism or do we want to tie all asynchronous
|
|
requests with one (probably DOM) event model ?</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority2"><a name="editing" id="editing"></a>1.13 Editing [2]</h3>
|
|
|
|
<p>Many <a title="" href="#cx">Component Extension</a>s will involve editing
|
|
functions, so the API must provide a method for access to editing
|
|
functionalities - character input, drawing interfaces, etc. These must be
|
|
available in a device independent manner. This requirement also means that
|
|
the available rendering space may need to be dynamically re-sized (see also
|
|
<a href="#size_rect"><b>1.1.2 linebreak, size and rectangle negotiation,
|
|
multiple rectangles</b></a>).</p>
|
|
|
|
<div class="div3">
|
|
<h4 class="priority1"><a name="N50A" id="N50A"></a>1.13.1 Editing mode
|
|
[1]</h4>
|
|
|
|
<p>The Component Extension API must provide an interface that allows the
|
|
notification of the toggle between "edit" and "view" modes. This API must be
|
|
present on both the Host implementation and the Component Extension.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="associations" id="associations"></a>1.14
|
|
associations/registrations/negociations [1]</h3>
|
|
|
|
<p>In order for the <a title="" href="#cx">Component Extension</a> to be able
|
|
to extend the Host DOM implementation, there must be a way for the <a
|
|
title="" href="#cx">Component Extension</a> to register its own DOM
|
|
implementation in the Host DOM implementation. In that case, the DOM
|
|
implementation Node factories in Document must create DOM Nodes using the
|
|
registered <a title="" href="#cx">Component Extensions</a> Node for the
|
|
corresponding types. Only the construction of the DOM nodes is affected by
|
|
the registrations, not the building of the DOM tree. If the <a title=""
|
|
href="#cx">Component Extension</a> does not provide a DOM implementation, the
|
|
<a title="" href="#host">Host implementation</a> must build the entire DOM
|
|
tree itself, including for the content addressed by the <a title=""
|
|
href="#cx">Component Extension</a>.</p>
|
|
|
|
<p>If the <a title="" href="#host">Host implementation</a> provides support
|
|
for XML 1.0 <a href="#XML">[XML]</a> documents, it must also implement the
|
|
namespaces support defined in the Namespaces recommendation <a
|
|
href="#Namespaces">[XML Namespaces]</a>. Namespace conflicts resolution
|
|
between <a title="" href="#cx">Component Extension</a>s must be resolved by
|
|
the <a title="" href="#host">Host implementation</a>. There must be a way for
|
|
the user to choose between <a title="" href="#cx">Component Extension</a>
|
|
implementations in case of conflicts.</p>
|
|
|
|
<p>The set of functionalities provided by the <a title="" href="#host">Host
|
|
implementation</a> must be accessible to the Component Extension. The same
|
|
applies for the <a title="" href="#cx">Component Extension</a>: the <a
|
|
title="" href="#">Host implementation</a> must have a way to query the set of
|
|
functionalities provided by the <a title="" href="#cx">Component
|
|
Extension</a>.</p>
|
|
|
|
<p>There are severals ways to extend the Host implementation. Technologies
|
|
such as XBL or IE behaviors must be considered.</p>
|
|
|
|
<p>The group might decide to come up with a modular architecture for an XML
|
|
parser that will permit some of the XML content to be handled by other
|
|
component. A general stream API should be addressed by the Component
|
|
Extension to gain access to their data.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority2"><a name="accessibility" id="accessibility"></a>1.15
|
|
Accessibility [2]</h3>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> API must provide for
|
|
accessibility requirements. Substantially, this reinforces the need for
|
|
several of the requirements listed already, such as the ability to specify a
|
|
content-type rather than a plugin, the provision and use of
|
|
device-independent interaction interfaces.</p>
|
|
|
|
<p>The User Agent Accessibility Guidelines <a href="#">[UUAG]</a> require
|
|
that access is provided for DOM interfaces, and "platform-specific
|
|
interfaces" (for example MSAA, the Java Accessibility API, etc) where they
|
|
exist.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="versioning" id="versioning"></a>1.16
|
|
Versioning [1]</h3>
|
|
|
|
<p>The <a title="" href="#cx">Component Extension</a> API should have an
|
|
identifiable versioning mechanism. The version information must change each
|
|
time the functionality is changed.</p>
|
|
|
|
<p>I am not sure it is necessary to discuss techniques here, as is done in
|
|
the following paragraph.</p>
|
|
|
|
<p>One technique for achieving this is to provide the naming for
|
|
functionalities, and use a mechanism like CC/PP for identifying the available
|
|
functionalities. Although this seems a little heavy for this purpose, and
|
|
seems to be better suited to using various unstandardized systems rather than
|
|
for a standardized system.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority2"><a name="storage" id="storage"></a>1.17
|
|
storage/persistence [2]</h3>
|
|
|
|
<p>The <a title="" href="#host">Host implementation</a> will allow the <a
|
|
title="" href="#cx">Component Extension</a> to save data in persistent
|
|
storage or a file system. This ability will be governed by the security model
|
|
associated with the <a title="" href="#cx">Component Extension</a>.</p>
|
|
|
|
<p>For example, a web page has the ability to store cookies in the file
|
|
system of the host. But a sandbox model exists there. Furthermore, the user
|
|
may block web pages from setting cookies.</p>
|
|
|
|
<p>The storage functionality can be divided into:</p>
|
|
<ol>
|
|
<li><p>Reading and Writing data specific to the <a title=""
|
|
href="#cx">Component Extension</a>. ('Private' Storage) Example, saving
|
|
high scores in a game. Storing cookies is an example in the context of a
|
|
web page.</p>
|
|
</li>
|
|
<li><p class="priority3">Reading and Writing data from the global data.
|
|
('Public' Storage). Example, reading list of addresses (or a specific
|
|
address) from an addressbook. <em>[3]</em></p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>For the first item, the <a title="" href="#host">Host implementation</a>
|
|
may provide the <a title="" href="#cx">Component Extension</a> APIs to get
|
|
and set values.</p>
|
|
|
|
<p>For example, to set:</p>
|
|
|
|
<table summary="Example" width="100%" bgcolor="#99ffff" border="1"
|
|
cellpadding="5" class="eg">
|
|
<tbody>
|
|
<tr>
|
|
<td><pre>HostSetAttribute("newscore", itoa(newScore));
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>to read,</p>
|
|
|
|
<table summary="Example" width="100%" bgcolor="#99ffff" border="1"
|
|
cellpadding="5" class="eg">
|
|
<tbody>
|
|
<tr>
|
|
<td><pre>length = HostGetDataSize ("highscores");
|
|
if (length > 0)
|
|
{
|
|
scoreString = memAlloc (length);
|
|
HostGetAttribute ("highscores", scoreString);
|
|
}
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>If the security settings of the <a title="" href="#cx">Component
|
|
Extension</a> do not allow these operations, then these operations will fail.
|
|
Or, the user maybe prompted for advice.</p>
|
|
|
|
<p>See also <a href="#WAP">[WAP Persistent Storage]</a>.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3 class="priority1"><a name="memory" id="memory"></a>1.18 Memory management
|
|
[1]</h3>
|
|
|
|
<p>Memory management would include APIs for</p>
|
|
<ul>
|
|
<li><p>Allocating a block of memory</p>
|
|
</li>
|
|
<li><p>Resizing the block of memory</p>
|
|
</li>
|
|
<li><p>Releasing the block of memory and</p>
|
|
</li>
|
|
<li><p>Flushing memory from the host's space.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<div class="issue">
|
|
<p class="prefix"><a name="memory-1" id="memory-1"></a><b>Issue
|
|
(memory-1):</b></p>
|
|
|
|
<p>how much memory should a plugin be allowed ? Probable answer: System
|
|
dependent. If the allocation function fails, an exception will be
|
|
generated.</p>
|
|
</div>
|
|
|
|
<div class="issue">
|
|
<p class="prefix"><a name="memory-2" id="memory-2"></a><b>Issue
|
|
(memory-2):</b></p>
|
|
|
|
<p>What about read/write? If the allocate APIs return a pointer, (as the
|
|
Netscape APIs do), what will prevent a plugin to do something like</p>
|
|
|
|
<table summary="Example" width="100%" bgcolor="#99ffff" border="1"
|
|
cellpadding="5" class="eg">
|
|
<tbody>
|
|
<tr>
|
|
<td><pre> char* s = MemAlloc (100);
|
|
s[2000] = 'a';
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>On a system that doesn't have a memory management unit, this may freeze
|
|
the system.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="N635" id="N635"></a>1.19 Security</h3>
|
|
|
|
<p>Security issues must be considered for each of the functionalities of the
|
|
Component Extension API.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="back">
|
|
|
|
<div class="div1">
|
|
<h2><a name="N642" id="N642"></a>A Glossary</h2>
|
|
<dl>
|
|
<dt class="label"><a name="cx" id="cx"></a>Component Extension</dt>
|
|
<dd><p>The term <b>Component Extension</b> (also well-known as
|
|
<b>plug-ins</b> in Web browsers) refers to any software in charge of
|
|
providing the client-side part of the Component Extension API. It is a
|
|
program that runs as part of the <a title="" href="#host">Host
|
|
implementation</a> and that is not part of content.</p>
|
|
</dd>
|
|
<dt class="label"><a name="host" id="host"></a>Host implementation</dt>
|
|
<dd><p>The term <b>Host implementation</b> refers to any software in
|
|
charge of providing the server-side part of the Component Extension
|
|
API. Softwares may include Web browsers, media players, <a title=""
|
|
href="#cx">Component Extensions</a>, and other programs (including
|
|
assistive technologies) that help in retrieving and processing (this
|
|
includes rendering) Web content.</p>
|
|
</dd>
|
|
<dt class="label"><a name="api" id="api"></a>Application Programming
|
|
Interface (API)</dt>
|
|
<dd><p>An application programming interface (API) defines how
|
|
communication may take place between applications. It is a set of
|
|
functions or methods used to access some functionality.</p>
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="references" id="references"></a>B References</h2>
|
|
<dl>
|
|
<dt class="label"><a name="CSS2" id="CSS2"></a>CSS Level 2</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/1998/REC-CSS2-19980512">Cascading Style
|
|
Sheets, level 2 Specification</a>, May 1998. Available at
|
|
http://www.w3.org/TR/1998/REC-CSS2-19980512</dd>
|
|
<dt class="label"><a name="DOM2Core" id="DOM2Core"></a>DOM Level 2 Core</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113">Document
|
|
Object Model Level 2 Core Specification</a>, November 2000. Available
|
|
at http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113</dd>
|
|
<dt class="label"><a name="DOM3Core" id="DOM3Core"></a>DOM Level 3 Core</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/DOM-Level-3-Core">Document Object Model
|
|
Level 3 Core Specification</a>, September 2001. Available at
|
|
http://www.w3.org/TR/DOM-Level-3-Core</dd>
|
|
<dt class="label"><a name="DOM2Style" id="DOM2Style"></a>DOM Level 2 Style
|
|
Sheets and CSS</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113">Document
|
|
Object Model Level 3 Views and Formatting Specification</a>, November
|
|
2000. Available at
|
|
http://www.w3.org/TR/2000/REC-DOM-Level-2-Style-20001113</dd>
|
|
<dt class="label"><a name="DOM3VF" id="DOM3VF"></a>DOM Level 3 Views and
|
|
Formatting</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/2000/WD-DOM-Level-3-Views-20001115/">Document
|
|
Object Model Level 3 Views and Formatting</a>, November 2000. Available
|
|
at http://www.w3.org/TR/2000/WD-DOM-Level-3-Views-20001115</dd>
|
|
<dt class="label"><a name="Netscape3" id="Netscape3"></a>Netscape
|
|
Plug-ins</dt>
|
|
<dd>Netscape <a
|
|
href="http://developer.netscape.com/docs/manuals/communicator/plugin/index.htm">Plug-in
|
|
Guide</a>, 1998. Available at
|
|
http://developer.netscape.com/docs/manuals/communicator/plugin/index.htm</dd>
|
|
<dt class="label"><a name="opentype" id="opentype"></a>OpenType</dt>
|
|
<dd>Microsoft <a
|
|
href="http://www.microsoft.com/typography/otspec/default.htm">OpenType
|
|
Specification</a>, April 2001. Available at
|
|
http://www.microsoft.com/typography/otspec/default.htm</dd>
|
|
<dt class="label"><a name="URIRef" id="URIRef"></a>RFC2396</dt>
|
|
<dd>IETF (Internet Engineering Task Force) <a
|
|
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396: Uniform Resource
|
|
Identifiers (URI): Generic Syntax</a>, eds. T. Berners-Lee, R.
|
|
Fielding, L. Masinter. August 1998. Available at
|
|
http://www.ietf.org/rfc/rfc2396.txt</dd>
|
|
<dt class="label"><a name="SVG1" id="SVG1"></a>SVG 1.0</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/SVG">Scalable Vector Graphics (SVG) 1.0
|
|
Specification</a>, September 2001. Available at
|
|
http://www.w3.org/TR/SVG</dd>
|
|
<dt class="label"><a name="SMIL20" id="SMIL20"></a>SMIL 2.0</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/smil20">Synchronized Multimedia Integration
|
|
Language (SMIL 2.0)</a>, August 2001. Available at
|
|
http://www.w3.org/TR/smil20</dd>
|
|
<dt class="label"><a name="SMILAnimation" id="SMILAnimation"></a>SMIL
|
|
Animation</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/smil-animation">SMIL Animation</a>,
|
|
September 2001. Available at http://www.w3.org/TR/smil-animation</dd>
|
|
<dt class="label"><a name="UAAG" id="UAAG"></a>User Agent Accessibility
|
|
Guidelines 1.0</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/UAAG10/">User Agent Accessibility Guidelines
|
|
1.0</a>, September 2001. Available at http://www.w3.org/TR/UAAG10</dd>
|
|
<dt class="label"><a name="WAP" id="WAP"></a>WAP Persistent Storage</dt>
|
|
<dd>WAP Forum (Wireless Application Forum) <a
|
|
href="http://www1.wapforum.org/tech/documents/WAP-227-PSTOR-20010530-a.pdf">WAP
|
|
Persistent Storage Interface </a>, May 2001. Available at
|
|
http://www1.wapforum.org/tech/documents/WAP-227-PSTOR-20010530-a.pdf</dd>
|
|
<dt class="label"><a name="XML" id="XML"></a>XML</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup
|
|
Language (XML) 1.0</a>, October 2000. Available at
|
|
http://www.w3.org/TR/2000/REC-xml-20001006</dd>
|
|
<dt class="label"><a name="InfoSet" id="InfoSet"></a>XML Information
|
|
set</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/2001/PR-xml-infoset-20010810">XML
|
|
Information Set</a>, August 2001. Available at
|
|
http://www.w3.org/TR/2001/PR-xml-infoset-20010810</dd>
|
|
<dt class="label"><a name="Namespaces" id="Namespaces"></a>XML
|
|
Namespaces</dt>
|
|
<dd>W3C (World Wide Web Consortium) <a
|
|
href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in
|
|
XML</a>, January 1999. Available at
|
|
http://www.w3.org/TR/1999/REC-xml-names-19990114</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="N79B" id="N79B"></a>C Contributors</h2>
|
|
|
|
<p>The people who contributed to this document are the members of the
|
|
HyperText Coordination Group and the participants of the Oslo face-to-face
|
|
meeting:</p>
|
|
|
|
<p>Jonny Axelsson (Opera), Bert Bos (W3C), Angel Diaz (IBM), Jon Ferraiolo
|
|
(Adobe), Max Froumentin (W3C), Rick Graham (Bitflash), Stein Kulseth (Opera),
|
|
Dean Jackson (W3C), Philippe Le Hégaret (W3C), Håkon Lie
|
|
(Opera), Rune Lillesveen (Opera), Chris Lilley, (W3C), Charles McCathieNevile
|
|
(W3C), Steven Pemberton (CWI/W3C), Vincent Quint (W3C, HyperText CG Chair),
|
|
Tapas Roy (Openwave), Peter Stark (Ericksson), Ray Whitmer (Netscape/AOL),
|
|
Steve Zilles (Adobe)</p>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|