DOM Level 3 will provide an API for loading XML documents into a DOM representation and for saving a DOM representation as a XML document.
Some environments, such as the Java [Java] or COM [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.
Requirements that apply to both loading and saving documents.
Documents must be able to be parsed from and saved to the following sources:
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.
While creating a new document using the DOM API, a mechanism must be provided to specify that the new document uses a pre-existing Abstract Schema and to cause that Abstract Schema to be loaded.
Note that while DOM Level 2 creation can specify a Abstract Schema when creating a document (public and system IDs for the external subset, and a string for the subset), DOM Level 2 implementations do not process the Abstract Schema's content. For DOM Level 3, the Abstract Schema's content must be read.
When processing a series of documents, all of which use the same Abstract Schema, implementations should be able to reuse the already parsed and loaded Abstract Schema rather than parsing 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 Abstract Schema section, of this specification block it or make it difficult to implement.
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.
Loading a document can cause the generation of errors including:
Saving a document can cause the generation of errors including:
This section, as well as the DOM Level 3 Abstract Schema section should use a common error reporting mechanism. Well-formedness and validity checking are in the domain of the Abstract Schema section, even though they may be commonly generated in response to an application asking that a document be loaded.
The following requirements apply to loading documents.
Parsers may have properties or options that can be set by applications. Examples include:
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.
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.
There are several features that can be controlled when saving an XML document. Some of these are:
The following items are not committed to, but are under consideration. Public feedback on these items is especially requested.
Note: This is done with the asynch loading.
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.
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.
Note: Won't happen.
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.
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.
<foo/><bar/>foobar<?xml version="1.0"?> <!DOCTYPE foo> foo and foobar
DocumentBuilder
(Sun) and DOMParser (Xerces).SAXException.toString and
SAXException.getMessage always the same? If not, we
need to add another attribute.true.DOMASBuilder interface in
the AS specDOMASBuilder interface in
the AS specDOMSystemException needs to
be defined as part of the error handling module that is to be
shared with AS. Common I/O type errors need to be defined for it,
so that they can be reported in a uniform way. A way to embed
errors or exceptions from the OS or language environment is needed,
to provide full information to applications that want it.false. Does this mean
that the default depends on the parser, or that some sort of an
error happens if a parse is attempted before resetting the
property, or what?false.false? Discussed at f2f. I'm not so sure now. Some of
the properties have somewhat non-standard behavior when
false - leaving out ER nodes or whitespace, for
example - and support of false will probably not even
be required.false. But validation should.true. Illegal for it to be false and
createEntityReferenceNodes to be true.
supported-mediatypes-only
feature on DOMBuilder.true during serialization that these changes
are discarded during serialization.false
then the attribute must be a level 1 node in which case this
information can safely be used.
Attr.specified
discussion.)SKIP an element in
DOMBuilderFilter::acceptNode?namespaceURI in core can be empty string, how
should that be dealt with in DOM LS?namespaceURI
of a Node is empty string, the serialization will
treat them as null, ignoring the prefix if any.FILTER_INTERRUPT if you want to
stop the processing of the document. Interrupting the processing of
the document does no longer garantee that the entire is XML
well-formed.This section defines an API for loading (parsing) XML documents [XML 1.0] into a DOM representation [DOM Level 3 Core] and for saving (serializing) a DOM representation as an XML document.
The proposal for loading is influenced by the Java APIs for XML Processing [JAXP] and by SAX2 [SAX].
The list of interfaces involved with the Loading and Saving XML documents is:
DOMImplementationLS
-- A new DOMImplementation interface that provides the
factory methods for creating the objects required for loading and
saving.DOMBuilder
-- A parser interface.DOMInputSource
-- Encapsulate information about the XML document to be
loaded.DOMEntityResolver
-- During loading, provides a way for applications to redirect
references to external entities.DOMBuilderFilter
-- Provide the ability to examine and optionally remove Element
nodes as they are being processed during the parsing of a
document.DOMWriter
-- An interface for writing out or serializing DOM documents.DocumentLS
-- Provides a client or browser style interface for loading and
saving.ParseErrorEvent
-- ParseErrorEvent is the event that is fired if there's an error
in the XML document being parsed using the methods of
DocumentLS.The interface within this section is considered fundamental, and must be fully implemented by all conforming implementations of the DOM Load and Save module.
DOMImplementationLS contains the factory methods
for creating objects that implement the DOMBuilder
(parser) and DOMWriter
(serializer) interfaces.
An object that implements DOMImplementationLS is obtained by doing a binding specific cast from DOMImplementation to DOMImplementationLS. Implementations supporting the Load and Save feature must implement the DOMImplementationLS interface on whatever object implements the DOMImplementation interface.
interface DOMImplementationLS { // DOMIMplementationLSMode const unsigned short MODE_SYNCHRONOUS = 1; const unsigned short MODE_ASYNCHRONOUS = 2; DOMBuilder createDOMBuilder(in unsigned short mode, in DOMString schemaType) raises(DOMException); DOMWriter createDOMWriter(); DOMInputSource createDOMInputSource(); };
An integer indicating which type of mode this is.
MODE_ASYNCHRONOUSDOMBuilder.MODE_SYNCHRONOUSDOMBuilder.createDOMBuilderDOMBuilder.
The newly constructed parser may then be configured by means of its
setFeature method, and used to parse documents by
means of its parse method.
mode of type unsigned
shortmode argument is either
MODE_SYNCHRONOUS or MODE_ASYNCHRONOUS, if
mode is MODE_SYNCHRONOUS then the DOMBuilder
that is created will operate in synchronous mode, if it's
MODE_ASYNCHRONOUS then the DOMBuilder
that is created will operate in asynchronous mode.schemaType of type
DOMStringDocument using the newly
created DOMBuilder.
Note that no lexical checking is done on the absolute URI. In order
to create a DOMBuilder
for any kind of schema types (i.e. the DOMBuilder will be free to
use any schema found), use the value null.
Note: For W3C XML Schema [XML Schema Part 1],
applications must use the value
"http://www.w3.org/2001/XMLSchema". For XML DTD [XML 1.0],
applications must use the value
"http://www.w3.org/TR/REC-xml". Other Schema languages
are outside the scope of the W3C and therefore should recommend an
absolute URI in order to use this method.
|
The newly created |
|
|
NOT_SUPPORTED_ERR: Raised if the requested mode or schema type is not supported. |
createDOMInputSourceDOMInputSource.
|
The newly created |
createDOMWriterThe DocumentLS interface provides a mechanism by which the content of a document can be replaced with the DOM tree produced when loading a URI, or parsing a string. The expectation is that an instance of the DocumentLS interface can be obtained by using binding-specific casting methods on an instance of the Document interface.
uses the default features.
interface DocumentLS { attribute boolean async; // raises(DOMException) on setting void abort(); boolean load(in DOMString uri); boolean loadXML(in DOMString source); DOMString saveXML(in Node snode) raises(DOMException); };
async of type
booleantrue
the load method returns control to the caller before the document
has completed loading. The default value of this attribute is
false.
false but we
need to check with Mozilla and IE.|
|
NOT_SUPPORTED_ERR: Raised if the implementation doesn't support the mode the attribute is being set to. |
abortload being invoked the loading
and parsing is immediately aborted. The possibly partial result of
parsing the document is discarded and the document is cleared.
loadParseErrorEvent).
If this method is called on a document that is currently loading,
the current load is interrupted and the new URI load is initiated.
uri of type
DOMString|
|
If async is set to |
loadXMLsource of type
DOMString|
|
|
saveXMLsnode of type
Nodenull the whole document is serialized, if it's
non-null the given node is serialized.|
|
The serialized document or |
|
|
WRONG_DOCUMENT_ERR: Raised if the node passed in as the node parameter is from an other document. |
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "LS-Load" and "3.0" (respectively)
to determine whether or not these interfaces are supported by the
implementation. In order to fully support them, an implementation
must also support the "Core" feature defined in the DOM Level 3
Core specification [DOM Level 3 Core].
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "LS-Load-Async" and "3.0"
(respectively) to determine whether or not the asynchronous mode is
supported by the implementation. In order to fully support the
asyncrhonous mode, an implementation must also support the
"LS-Load" feature defined in this section.
Please, refer to additional information about conformance in the DOM Level 3 Core specification [DOM Level 3 Core].
This interface represents a single input source for an XML entity.
This interface allows an application to encapsulate information about an input source in a single object, which may include a public identifier, a system identifier, a byte stream (possibly with a specified encoding), and/or a character stream.
The exact definitions of a byte stream and a character stream are binding dependent.
There are two places that the application will deliver this
input source to the parser: as the argument to the
parse method, or as the return value of the DOMEntityResolver.resolveEntity
method.
The DOMBuilder
will use the DOMInputSource object to determine how to
read XML input. If there is a character stream available, the
parser will read that stream directly; if not, the parser will use
a byte stream, if available; if neither a character stream nor a
byte stream is available, the parser will attempt to open a URI
connection to the resource identified by the system identifier.
A DOMInputSource object belongs to the application:
the parser shall never modify it in any way (it may modify a copy
if necessary).
Note: Eventhough all attributes in this interface are writable the DOM implementation is expected to never mutate a DOMInputSource.
interface DOMInputSource { attribute DOMInputStream byteStream; attribute DOMReader characterStream; attribute DOMString stringData; attribute DOMString encoding; attribute DOMString publicId; attribute DOMString systemId; attribute DOMString baseURI; };
baseURI of type
DOMStringbyteStream of type
DOMInputStreamcharacterStream
of type DOMReaderencoding of type
DOMStringpublicId of type
DOMStringstringData of type
DOMStringsystemId of type
DOMStringThis interface represents a load event object that signals the completion of a document load.
interface LSLoadEvent : events::Event { readonly attribute Document newDocument; readonly attribute DOMInputSource inputSource; };
inputSource of type DOMInputSource,
readonlynewDocument of type
Document, readonlyThis interface represents a progress event object that notifies
the application about progress as a document is parsed. It extends
the Event interface defined in [DOM Level 3
Events].
interface LSProgressEvent : events::Event { readonly attribute DOMInputSource inputSource; readonly attribute unsigned long position; readonly attribute unsigned long totalSize; };
inputSource of type
DOMInputSource,
readonlyposition of type
unsigned long, readonlytotalSize of type
unsigned long, readonlyDOMEntityResolver Provides a way for applications
to redirect references to external entities.
Applications needing to implement customized handling for
external entities must implement this interface and register their
implementation by setting the entityResolver attribute
of the DOMBuilder.
The DOMBuilder
will then allow the application to intercept any external entities
(including the external DTD subset and external parameter entities)
before including them.
Many DOM applications will not need to implement this interface, but it will be especially useful for applications that build XML documents from databases or other specialized input sources, or for applications that use URNs.
Note: DOMEtityResolver is based on the SAX2
[SAX]
EntityResolver interface.
interface DOMEntityResolver { DOMInputSource resolveEntity(in DOMString publicId, in DOMString systemId, in DOMString baseURI) raises(DOMSystemException); };
resolveEntityDOMBuilder
will call this method before opening any external entity except the
top-level document entity (including the external DTD subset,
external entities referenced within the DTD, and external entities
referenced within the document element); the application may
request that the DOMBuilder
resolve the entity itself, that it use an alternative URI, or that
it use an entirely different input source.DOMBuilder
must resolve it fully before reporting it to the application
through this interface.
publicId of type
DOMStringnull if none was supplied.systemId of type
DOMStringbaseURI of type
DOMStringnull if there is no base URI.|
A |
|
|
Any |
DOMBuilderFilters provide applications the ability
to examine nodes as they are being constructed during a parse. As
each node is examined, it may be modified or removed, or the entire
parse may be terminated early.
At the time any of the filter methods are called by the parser,
the owner Document and DOMImplementation objects exist and are
accessible. The document element is never passed to the
DOMBuilderFilter methods, i.e. it is not possible to
filter out the document element.
All validity checking while reading a document occurs on the source document as it appears on the input stream, not on the DOM document as it is built in memory. With filters, the document in memory may be a subset of the document on the stream, and its validity may have been affected by the filtering.
All default content, including default attributes, must be passed to the filter methods.
Any exception raised in the filter are ignored by the DOMBuilder.
The constants FILTER_ACCEPT,
FILTER_REJECT and FILTER_SKIP are defined
in DOM Level 2 Traversal [DOM Level 2 Traversal and
Range].
interface DOMBuilderFilter { const unsigned short FILTER_INTERRUPT = 4; unsigned short startContainer(in Node snode); unsigned short acceptNode(in Node enode); readonly attribute unsigned long whatToShow; };
whatToShow of type
unsigned long, readonlyDOMBuilder
what types of nodes to show to the filter. See
NodeFilter for definition of the constants. The
constant SHOW_ATTRIBUTE is meaningless here, attribute
nodes will never be passed to a
DOMBuilderFilter.acceptNodeenode of type
Node|
|
|
startContainerElement start tag has been scanned, but before
the remainder of the Element is processed. The intent
is to allow the element, including any children, to be efficiently
skipped. Note that only element nodes are passed to the
startContainer function.startContainer for
filtering will include all of the Element's attributes, but none of
the children nodes. The Element may not yet be in place in the
document being constructed (it may not have a parent node.)startContainer filter function may access or change
the attributers for the Element. Changing Namespace declarations
will have no effect on namespace resolution by the parser.snode of type
Node|
|
Returning any other values will result in unspecified behavior. |
ParseErrorEvent is the event that is fired if there's an error in the XML document being parsed.
interface ParseErrorEvent : events::Event { readonly attribute DOMError error; };
error of type
DOMError, readonly0 if there is no error.A interface to an object that is able to build a DOM tree from various input sources.
DOMBuilder provides an API for parsing XML
documents and building the corresponding DOM document tree. A
DOMBuilder instance is obtained from the DOMImplementationLS
interface by invoking its createDOMBuildermethod.
As specified in [DOM Level 3 Core], when a document is first made available via the DOMBuilder:
Text node for each block of
text. The Text nodes are into "normal" form: only
structure (e.g., elements, comments, processing instructions, CDATA
sections, and entity references) separates Text nodes,
i.e., there are neither adjacent Text nodes nor empty
Text nodes.value and
nodeValue attributes of an Attr node
initially return the XML
1.0 normalized value. However, if the features
validate-if-schema and
datatype-normalization are set to true,
depending on the attribute normalization used, the attribute values
may differ from the ones obtained by the XML 1.0 attribute
normalization. If the feature
datatype-normalization is not set to
true, the XML 1.0 attribute normalization is
guaranteed to occur, and if attributes list does not contain
namespace declarations, the attributes attribute on
Element node represents the property [attributes]
defined in [XML Information set] .
datatype-normalization is set to
true.Asynchronous DOMBuilder objects are expected to
also implement the events::EventTarget interface so
that event listeners can be registerd on asynchronous
DOMBuilder objects.
Events supported by asynchronous DOMBuilder
are:
LSLoadEventLSProgressEventNote: All events defined in this specification use the
namespace URI "http://www.w3.org/2002/DOMLS".
DOMBuilders have a number of named features that
can be queried or set. The name of DOMBuilder features
must be valid XML names. Implementation specific features
(extensions) should choose a implementation specific prefix to
avoid name collisions.
Even if all features must be recognized by all implementations,
being able to set a state (true or false)
is not always required. The following list of recognized features
indicates the definitions of each feature state, if setting the
state to true or false must be supported
or is optional and, which state is the default one:
"cdata-sections"Document.setNormalizationFeature in [DOM Level 3
Core]."comments"Document.setNormalizationFeature in [DOM Level 3
Core]."charset-overrides-xml-encoding"trueDOMInputSource
overrides encodings from the protocol.false"datatype-normalization"Document.setNormalizationFeature in [DOM Level 3
Core]."entities"Document.setNormalizationFeature in [DOM Level 3
Core]."canonical-form"Document.setNormalizationFeature in [DOM Level 3
Core]."infoset"Document.setNormalizationFeature in [DOM Level 3
Core]."namespaces"Document.setNormalizationFeature in [DOM Level 3
Core]."namespace-declarations"Document.setNormalizationFeature in [DOM Level 3
Core]."supported-mediatypes-only"truefalse"validate-if-schema"Document.setNormalizationFeature in [DOM Level 3
Core]."validation"Document.setNormalizationFeature in [DOM Level 3
Core]."whitespace-in-element-content"Document.setNormalizationFeature in [DOM Level 3
Core].interface DOMBuilder { attribute DOMEntityResolver entityResolver; attribute DOMErrorHandler errorHandler; attribute DOMBuilderFilter filter; void setFeature(in DOMString name, in boolean state) raises(DOMException); boolean canSetFeature(in DOMString name, in boolean state); boolean getFeature(in DOMString name) raises(DOMException); Document parseURI(in DOMString uri); Document parse(in DOMInputSource is) raises(DOMSystemException); // ACTION_TYPES const unsigned short ACTION_REPLACE = 1; const unsigned short ACTION_APPEND_AS_CHILDREN = 2; const unsigned short ACTION_INSERT_AFTER = 3; const unsigned short ACTION_INSERT_BEFORE = 4; void parseWithContext(in DOMInputSource is, in Node cnode, in unsigned short action) raises(DOMException); };
A set of possible actions for the parseWithContext
method.
ACTION_APPEND_AS_CHILDRENElement or a DocumentFragment.ACTION_INSERT_AFTERElement.ACTION_INSERT_BEFOREElement.ACTION_REPLACEElement,
Text, CDATASection, Comment,
ProcessingInstruction, or EntityReference
node.entityResolver of type
DOMEntityResolverDOMEntityResolver
has been specified, each time a reference to an external entity is
encountered the DOMBuilder will pass the public and
system IDs to the entity resolver, which can then specify the
actual source of the entity.errorHandler of type
DOMErrorHandlerDOMDocumentBuilder will call back to
the errorHandler with the error information. When the
document loading process calls the error handler the node closest
to where the error occured is passed to the error handler, if the
implementation is unable to pass the node where the error occures
the document Node is passed to the error handler. In addition to
passing the Node closest to to where the error occured, the
implementation should also pass any other valuable information to
the error handler, such as file name, line number, and so on.
Mutations to the document from within an error handler will result
in implementation dependent behavour.filter of type DOMBuilderFilterElement node. The filter implementation can choose to
remove the element from the document being constructed (unless the
element is the document element) or to terminate the parse early.
If the document is being validated when it's loaded the validation
happens before the filter is called.canSetFeaturename of type
DOMStringstate of type
booleantrue or
false).|
|
|
getFeaturename of type
DOMString|
|
The current state of the feature ( |
|
|
NOT_FOUND_ERR: Raised when the |
parseDOMInputSource.
is of type DOMInputSourceDOMInputSource
from which the source document is to be read.|
|
If the |
|
|
Exceptions raised by |
parseURIuri of type
DOMString|
|
If the |
parseWithContextDOMInputSource
and insert the content into an existing document at the position
specified with the contextNode and action
arguments. When parsing the input stream the context node is used
for resolving unbound namespace prefixes.is of type DOMInputSourceDOMInputSource
from which the source document is to be read.cnode of type
NodeDocument node, a
DocumentFragment node, or a node of a type that is
allowed as a child of an element, e.g. it can not be an attribute
node.action of type
unsigned short|
|
NOT_SUPPORTED_ERR: Raised when the NO_MODIFICATION_ALLOWED_ERR: Raised if the context node is readonly. |
setFeatureDOMBuilder to recognize a feature
name but to be unable to set its value.
name of type
DOMStringstate of type
booleantrue or
false).|
|
NOT_SUPPORTED_ERR: Raised when the NOT_FOUND_ERR: Raised when the |
A DOM application may use the hasFeature(feature,
version) method of the DOMImplementation
interface with parameter values "LS-Save" and "3.0" (respectively)
to determine whether or not these interfaces are supported by the
implementation. In order to fully support them, an implementation
must also support the "Core" feature defined in the DOM Level 3
Core specification [DOM Level 3 Core]. Please, refer to
additional information about
conformance in the DOM Level 3 Core specification [DOM Level 3
Core].
DOMWriter provides an API for serializing (writing)
a DOM document out in an XML document. The XML data is written to
an output stream, the type of which depends on the specific
language bindings in use.
During serialization of XML data, namespace fixup is done when
possible. [DOM Level 2 Core] allows empty
strings as a real namespace URI. If the namespaceURI
of a Node is empty string, the serialization will
treat them as null, ignoring the prefix if any.
DOMWriter accepts any node type for serialization.
For nodes of type Document or Entity,
well formed XML will be created if possible. The serialized output
for these node types is either as a Document or an External Entity,
respectively, and is acceptable input for an XML parser. For all
other types of nodes the serialized form is not specified, but
should be something useful to a human for debugging or diagnostic
purposes. Note: rigorously designing an external (source) form for
stand-alone node types that don't already have one defined in [XML 1.0]
seems a bit much to take on here.
Within a Document, DocumentFragment, or Entity being serialized, Nodes are processed as follows
writeNode
defined in the DOMWriter interface, output the entity
expansion but no namespace fixup is done. The resulting output will
be valid as an external entity.&entityName;" in the output. Child nodes
(the expansion) of the entity reference are ignored.true, CDATA sections are split, and
the unrepresentable characters are serialized as numeric character
references in ordinary content. The exact position and number of
splits is not specified.false, unrepresentable characters
in a CDATA section are reported as errors. The error is not
recoverable - there is no mechanism for supplying alternative
characters and continuing with the serialization.Note: The serialization of a DOM Node does not always
generate a well-formed XML
document, i.e. a DOMBuilder
might through fatal errors when parsing the resulting
serialization.
Within the character data of a document (outside of markup), any characters that cannot be represented directly are replaced with character references. Occurrences of '<' and '&' are replaced by the predefined entities < and &. The other predefined entities (>, &apos, etc.) are not used; these characters can be included directly. Any character that can not be represented directly in the output character encoding is serialized as a numeric character reference.
Attributes not containing quotes are serialized in quotes. Attributes containing quotes but no apostrophes are serialized in apostrophes (single quotes). Attributes containing both forms of quotes are serialized in quotes, with quotes within the value represented by the predefined entity ". Any character that can not be represented directly in the output character encoding is serialized as a numeric character reference.
Within markup, but outside of attributes, any occurrence of a character that cannot be represented in the output character encoding is reported as an error. An example would be serializing the element <LaCañada/> with the encoding="us-ascii".
When requested by setting the normalize-characters
feature on DOMWriter, all data to be serialized, both
markup and character data, is W3C Text normalized according to the
rules defined in [CharModel]. The W3C Text
normalization process affects only the data as it is being written;
it does not alter the DOM's view of the document after
serialization has completed.
Namespaces are fixed up during serialization, the serialization process will verify that namespace declarations, namespace prefixes and the namespace URIs associated with Elements and Attributes are consistent. If inconsistencies are found, the serialized form of the document will be altered to remove them. The algorithm used for doing the namespace fixup while serializing a document is a combination of the algorithms used for lookupNamespaceURI and lookupNamespacePrefix .
Any changes made affect only the namespace prefixes and declarations appearing in the serialized data. The DOM's view of the document is not altered by the serialization operation, and does not reflect any changes made to namespace declarations or prefixes in the serialized output.
While serializing a document the serializer will write out
non-specified values (such as attributes whose
specified is false) if the
discard-default-content feature is set to
true. If the discard-default-content flag
is set to false and a schema is used for validation,
the schema will be also used to determine if a value is specified
or not. If no schema is used, the specified flag on
attribute nodes is used to determine if attribute values should be
written out.
Ref to Core spec (1.1.9, XML namespaces, 5th paragraph) entity
ref description about warning about unbound entity refs. Entity
refs are always serialized as &foo;, also mention
this in the load part of this spec.
DOMWriters have a number of named features that can
be queried or set. The name of DOMWriter features must
be valid XML names. Implementation specific features (extensions)
should choose an implementation dependent prefix to avoid name
collisions.
Here is a list of features that must be recognized by all implementations.
Note: Using these features does affect the
Node being serialized, only its serialized form is
affected.
"discard-default-content"Document.setNormalizationFeature in [DOM Level 3
Core]."entities"Document.setNormalizationFeature in [DOM Level 3
Core]."canonical-form"true"format-pretty-print" to
false.false"format-pretty-print"truefalse"normalize-characters"Document.setNormalizationFeature in [DOM Level 3
Core]. Unlike in the Core, the default value for this feature
is true."split-cdata-sections"Document.setNormalizationFeature in [DOM Level 3
Core]."validation"Document.setNormalizationFeature in [DOM Level 3
Core]."whitespace-in-element-content"Document.setNormalizationFeature in [DOM Level 3
Core].interface DOMWriter { void setFeature(in DOMString name, in boolean state) raises(DOMException); boolean canSetFeature(in DOMString name, in boolean state); boolean getFeature(in DOMString name) raises(DOMException); attribute DOMString encoding; attribute DOMString newLine; attribute DOMWriterFilter filter; attribute DOMErrorHandler errorHandler; boolean writeNode(in DOMOutputStream destination, in Node wnode) raises(DOMSystemException); DOMString writeToString(in Node wnode) raises(DOMException); };
encoding of type
DOMStringnull or empty, but
the item to be written, or the owner document of the item,
specifies an encoding (i.e. the "actualEncoding" from the document)
specified encoding, that value will be used.null.errorHandler of type
DOMErrorHandlerfilter of type DOMWriterFilternewLine of type
DOMStringnullnull.canSetFeaturename of type
DOMStringstate of type
booleantrue or
false).|
|
|
getFeaturename of type
DOMString|
|
The current state of the feature ( |
|
|
NOT_FOUND_ERR: Raised when the |
setFeatureDOMWriter to recognize a feature
name but to be unable to set its value.
name of type
DOMStringstate of type
booleantrue or
false).|
|
NOT_SUPPORTED_ERR: Raised when the Raise a NOT_FOUND_ERR When the |
writeNodeDOMWriter. Writing a Document or
Entity node produces a serialized form that is well formed XML,
when possible (Entity nodes might not always be well formed XML in
themselves). Writing other node types produces a fragment of text
in a form that is not fully defined by this document, but that
should be useful to a human for debugging or diagnostic
purposes.destination of type
DOMOutputStreamwnode of type
NodeDocument or Entity node to be
written. For other node types, something sensible should be
written, but the exact serialized form is not specified.|
|
Returns |
|
|
This exception will be raised in response to any sort of IO or system error that occurs while writing to the destination. It may wrap an underlying system exception. |
writeToStringDOMWriter. The result of
serializing the node is returned as a DOMString (this method
completely ignores all the encoding information avaliable). Writing
a Document or Entity node produces a serialized form that is well
formed XML. Writing other node types produces a fragment of text in
a form that is not fully defined by this document, but that should
be useful to a human for debugging or diagnostic purposes.wnode of type
Node|
|
Returns the serialized data, or |
|
|
DOMSTRING_SIZE_ERR: Raised if the resulting string is too long
to fit in a |
DOMWriterFilters provide applications the ability
to examine nodes as they are being serialized.
DOMWriterFilter lets the application decide what nodes
should be serialized or not.
interface DOMWriterFilter : traversal::NodeFilter { readonly attribute unsigned long whatToShow; };
whatToShow of type
unsigned long, readonlyDOMWriter
what types of nodes to show to the filter. See
NodeFilter for definition of the constants. The
constant SHOW_ATTRIBUTE is meaningless here, attribute
nodes will never be passed to a DOMWriterFilter.