4.2.
Level 3 Events Requirements
The DOM Level 3 Events specification will attempt to address some of the
remaining issues from the DOM Level 2 Event specification as well as a
couple or requested enhancements to the model. It will not attempt to
redesign the model nor will attempt to define any additional event models.
4.2.1.
EventListener grouping
The specification must define a technique for registering
EventListeners in groups. These groups will then have
specified behavior in which attempts to modify the flow of an event will
be restricted and affected only the group to which the
EventListener in question belongs.
It is also required that whatever technique is specified to accomplish
this purpose be compatible with the existing DOM Level 2 Event model and
any EventListeners registered using DOM Level 2 Event model
methods.
4.2.2.
Key event set
The specification must define a set of key events to handle keyboard
input. This key event set must be fully internationalizable. It is
hoped that this key event set will be compatible with existing key event
sets used in current systems however this is not a requirement.
The specification should attempt to define a set of input events to
handle IME based keyboard input. It is expected that this requirement
will depend heavily on any key event set defined by the specification.
4.2.4.
Device independent event set
The specification must define a device independent event set. This event
set should allow notification of typical user interaction with a document
without requiring the use of either mouse events or key events.
4.3.
Content Models and Validation Use Cases and Requirements
The content model referenced in these use cases/requirements is an abstraction and does not refer to DTDs or XML Schemas or any transformations between the two.
For the CM-editing and document-editing worlds, the following use cases and requirements are common to both:
Use Cases:
- CU1. Modify an existing content model because it needs to be updated.
- CU2. Associating a content model (external and/or internal) with a document, or changing the current association.
- CU3. Using the same external content model with several documents, without having to reload it.
Requirements:
- CR1. Retrieve information from content model.
- CR2. Load an existing content model, perhaps independently from a document.
- CR3. Being able to determine if a document has a content model associated with it.
Specific to the CM-editing world, the following are use cases and requirements:
Use Cases:
- CMU1. Create a new content model.
- CMU2. Clone/map all or parts of an existing content model to a new or existing content model.
- CMU3. Save a content model in a separate file. For example, a DTD can be broken up into reusable pieces, which are then brought in via entity references, these can then be saved in a separate file.
- CMU4. Partial content model checking. For example, only certain portions of the content model need be validated.
Requirements:
- CMR1. Create a new content model object.
- CMR2. View and modify all parts of the content model.
- CMR3. Validate the content model itself. For example, if an element/attribute is inserted incorrectly into the content model.
- CMR4. Serialize the content model.
- CMR5. Clone all or parts of an existing content model.
- CMR6. Validate portions of the XML document against the content model.
Specific to the document-editing world, the following are use cases and requirements:
Use Cases:
- DU1. For editing documents with an associated content model, provide the assistance necessary so that valid documents can be modified and remain valid.
- DU2. For editing documents with an associated content model, provide the assistance necessary to transform an invalid document into a valid one.
Requirements:
- DR1. Being able to determine if the document is not well-formed, and if not, be given enough assistance to locate the error.
- DR2. Being able to determine if the document is not namespace well-formed, and if not, be given enough assistance to locate the error.
- DR3. Being able to determine if the document is not valid with respect to its associated content model, and if not, give enough assistance to locate the error.
- DR4. Being able to determine if specific modifications to a document would make it become invalid.
- DR5. Retrieve information from the content model. For example, getting a list of all the defined element names for document editing purposes.
4.4.
Load and Save Requirements
DOM Level 3 will provide an API for loading XML source documents into a
DOM representation and for saving a DOM representation as a XML document.
Some environments, such as the Java platform or COM, have their own ways
to persist objects to streams and to restore them. There is no direct
relationship between these mechanisms and the DOM load/save mechanism. This
specification defines how to serialize documents only to and from XML
format.
4.4.1.
General Requirements
Requirements that apply to both loading and saving documents.
4.4.1.1.
Document Sources
Documents must be able to be parsed from and saved to the following
sources:
- Input and Output Streams
- URIs
- Files
Note that Input and Output streams take care of the in memory case.
One point of caution is that a stream doesn't allow a base URI to be defined
against which all relative URIs in the document are resolved.
4.4.1.2.
Content Model Loading
While creating a new document using the DOM API, a mechanism must be
provided to specify that the new document uses a pre-existing Content
Model and to cause that Content Model to be loaded.
Note that while DOM Level 2 creation can specify a Content Model
when creating a document (public and system IDs for the external subset, and a
string for the internal subset), DOM Level 2 implementations do not process the
Content Model's content. For DOM Level 3, the Content Model's content must be
be read.
4.4.1.3.
Content Model Reuse
When processing a series of documents, all of which use the same
Content Model, implementations should be able to reuse the already parsed and loaded
Content Model rather than reparsing it again for each new document.
This feature may not have an explicit DOM API associated with it,
but it does require that nothing in this section, or the Content Model section,
of this specification block it or make it difficult to implement.
4.4.1.4.
Entity Resolution
Some means is required to allow applications to map public and
system IDs to the correct document. This facility should provide sufficient
capability to allow the implementation of catalogs, but providing catalogs
themselves is not a requirement. In addition XML Base needs to be
addressed.
4.4.1.5.
Error Reporting
Loading a document can cause the generation of errors including:
- I/O Errors, such as the inability to find or open the specified
document.
XML well formedness errors.
Validity errors
Saving a document can cause the generation of errors including:
- I/O Errors, such as the inability to write to a specified
stream, url, or file.
Improper constructs, such as '--' in comments, in the DOM that
cannot be represented as well formed XML.
This section, as well as the DOM Level 3 Content Model section
should use a common error reporting mechanism. Well-formedness and validity
checking are in the domain of the Content Model section, even though they may
be commonly generated in response to an application asking that a document be
loaded.
4.4.2.
Load Requirements
The following requirements apply to loading documents.
4.4.2.1.
Parser Properties and Options
Parsers may have properties or options that can be set by
applications. Examples include:
- Expansion of entity references.
- Creation of entity ref nodes.
- Handling of white space in element content.
- Enabling of namespace handling.
- Enabling of content model validation.
A mechanism to set properties, query the state of properties, and to
query the set of properties supported by a particular DOM implementation is
required.
4.4.3.
XML Writer Requirements
The fundamental requirement is to write a DOM document as XML source.
All information to be serialized should be available via the
normal DOM API.
4.4.3.1.
XML Writer Properties and Options
There are several options that can be defined when saving an XML
document. Some of these are:
- Saving to Canonical XML format.
- Pretty Printing.
- Specify the encoding in which a document is written.
- How and when to use character entities.
- Namespace prefix handling.
- Saving of Content Models.
- Handling of external entities.
4.4.3.2.
Content Model Saving
Requirement from the Content Model group.
4.4.4.
Other Items Under Consideration
The following items are not committed to, but are under consideration.
Public feedback on these items is especially requested.
4.4.4.1.
Incremental and/or Concurrent Parsing
Provide the ability for a thread that requested the loading of a
document to continue execution without blocking while the document is being
loaded. This would require some sort of notification or completion event when
the loading process was done.
Provide the ability to examine the partial DOM representation before
it has been fully loaded.
In one form, a document may be loaded asynchronously while a DOM
based application is accessing the document. In another form, the application
may explicitly ask for the next incremental portion of a document to be loaded.
4.4.4.2.
Filtered Save
Provide the capability to write out only a part of a document. May
be able to leverage TreeWalkers, or the Filters associated with TreeWalkers, or
Ranges as a means of specifying the portion of the document to be written.
4.4.4.3.
Document Fragments
Document fragments, as specified by the XML Fragment specification,
should be able to be loaded. This is useful to applications that
only need to process some part of a large document. Because the DOM is
typically implemented as an in-memory representation of a document, fully
loading large documents can require large amounts of memory.
XPath should also be considered as a way to identify XML Document
fragments to load.
4.4.4.4.
Document Fragments in Context of Existing DOM
Document fragments, as specified by the XML Fragment specification,
should be able to be loaded into the context of an existing document at a point
specified by a node position, or perhaps a range. This is a separate feature
than simply loading document fragments as a new Node.
4.5.
Views and Formatting Requirements
An important aspect of the DOM is the strong separation between the
structure of a document and its presentations or views. The abstract structure
and value of the document content is modelled by the DOM core. The physical
characteristics and state of the presentation will be modelled by the views and
formatting module.
While the abstract model is persistent, the presentation is active and
temporary, responding to user and environment events as well as document
mutation. The state of the presentation can not generally be manipulated as
directly as the DOM core nodes. The API must allow querying and responding to
changes in the physical characteristics of the presentation and its
environment.
(ED: We need a FAQ entry elaborating on why the presentation
characteristics are generally not mutable.)
The physical characteristics of the presentation are very tied to the
medium and style system being used. An abstract layer must exist to allow for
generalization of common properties of presentations on arbitrary media and
style systems. Concrete mappings must also be available for prevalent
presentation media and style systems.
The API must support multiple simultaneous dissimilar presentations of a
document. The API must permit enumeration of current views. The API may permit
creation new views of the document. The API must provide access to the values
of characteristics of the presentation of individual nodes within the document.
These are the actual values that have been derived from the style system that
are used to render the document. The API may also provide the ability to listen
for events fired as a result of presentational changes. Properties of the
presentation of DOM nodes in a visual medium may include actual position,
dimensions, visibility, colors, fonts, generated text, and so on.
The API must make it possible to find the document nodes being presented
by a particular part or location within the presentation.
The API must make it possible to request user selection and focus.
4.5.1.
Use Cases
(ED: More use cases required.)
4.5.1.1.
Selection and Focus
4.5.1.2.
Window.screen Functionality Implemented in Current
Browsers
- Get information on the dimensions or color depth of the
screen.
- Select different graphics depending upon the screen
capabilities.
- Use the browser window as an application window for a web
application.
- Position controls relative to the environment / screen
characteristics of the rendering device .
4.5.1.3.
Multiple Views
- Split view in a browser or editor which might have different
formatting characteristics.
- Synchronization of view-specific state (e.g. selection and
focus) between multiple similar or dissimilar views on the same document in an
editing environment.
- Tool tips, annotations or other visual enhancements that need to
be positioned relative to the rendering of a specific element.
- Hit testing for an application in a visual medium where feedback
is provided in response to user events.
- Color picker application that displays actual color used for
element or area.