This class holds the list of registered DOMImplementations. More...
|Configurable memory manager. More...|
|Utilities that must be implemented in a platform-specific way. More...|
|CDATA sections are used to escape blocks of text containing characters that would otherwise be regarded as markup. More...|
|This interface inherits from |
|The DOMConfiguration interface represents the configuration of a document and maintains a table of recognized parameters. More...|
|DOMDocumentFragment is a "lightweight" or "minimal" DOMDocument object. More...|
|By far the vast majority of objects (apart from text) that authors encounter when traversing a document are |
|This interface represents an entity, either parsed or unparsed, in an XML document. More...|
|DOMError is an interface that describes an error. More...|
|Basic interface for DOM error handlers. More...|
|DOMLocator is an interface that describes a location. More...|
|This interface represents a single input source for an XML entity. More...|
|This interface represents an output destination for data. More...|
|DOMLSParser provides an API for parsing XML documents and building the corresponding DOM document tree. More...|
|DOMLSResourceResolver provides a way for applications to redirect references to external entities. More...|
|Filters are objects that know how to "filter out" nodes. More...|
|This interface represents a notation declared in the DTD. More...|
|Range operations may throw a |
|When associating an object to a key on a node using |
|The evaluation of XPath expressions is provided by |
|typedef DOMNode *||DOMNodeSPtr|
|typedef DOMAttr *||DOMAttrSPtr|
|typedef DOMElement *||DOMElementSPtr|
|MakeXMLException (XMLPlatformUtilsException, XMLUTIL_EXPORT) inline XMLSize_t XMLPlatformUtils|
This class holds the list of registered DOMImplementations.
DOMLSSerializer provides an API for serializing (writing) a DOM document out in an XML document.
This interface permits a DOM implementer to supply one or more implementations, based upon requested features and versions.
This provides an application with an implementation independent starting point.
DOMLSParserFilter provide applications the ability to examine nodes as they are being created during the parse process.
DOMLSParserFilter lets the application decide what nodes should be in the output DOM tree or not.
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.
DOMLSSerializer accepts any node type for serialization. For nodes of type
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 seems a bit much to take on here.
Within a Document or Entity being serialized, Nodes are processed as follows Documents are written including an XML declaration and a DTD subset, if one exists in the DOM. Writing a document node serializes the entire document. Entity nodes, when written directly by
write defined in the
DOMLSSerializer interface, output the entity expansion but no namespace fixup is done. The resulting output will be valid as an external entity. Entity References nodes are serializes as an entity reference of the form
"&entityName;") in the output. Child nodes (the expansion) of the entity reference are ignored. CDATA sections containing content characters that can not be represented in the specified output encoding are handled according to the "split-cdata-sections" feature.If the feature is
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. If the feature is
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. All other node types (DOMElement, DOMText, etc.) are serialized to their corresponding XML source form.
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&xF1;ada/> with the encoding="us-ascii".
When requested by setting the
normalize-characters feature on
DOMLSSerializer, all data to be serialized, both markup and character data, is W3C Text normalized according to the rules defined in . 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 seralizing a document is a combination of the algorithms used for lookupNamespaceURI and lookupPrefix. previous paragraph to be defined closer here.
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
false) if the
output-default-values feature is set to
true. If the
output-default-values flag is set to
false and the
use-abstract-schema feature is set to
true the abstract schema will be used to determine if a value is specified or not, if
use-abstract-schema is not set 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.
When serializing a document the DOMLSSerializer checks to see if the document element in the document is a DOM Level 1 element or a DOM Level 2 (or higher) element (this check is done by looking at the localName of the root element). If the root element is a DOM Level 1 element then the DOMLSSerializer will issue an error if a DOM Level 2 (or higher) element is found while serializing. Likewise if the document element is a DOM Level 2 (or higher) element and the DOMLSSerializer sees a DOM Level 1 element an error is issued. Mixing DOM Level 1 elements with DOM Level 2 (or higher) is not supported.
DOMLSSerializers have a number of named features that can be queried or set. The name of
DOMLSSerializer 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 properties that must be recognized by all implementations.
CDATASectioncontains an unrepresentable character.
EntityReferencenodes when serializing.
EntityReferencenodes as XML entity references.
Textnodes to determine if a text node should be written out or not.
Attrnodes, and so on) to decide what attributes and content should be serialized or not. Note that the
Attrnodes in itself is not always reliable, it is only reliable when it is set to
falsesince the only case where it can be set to
falseis if the attribute was created by a Level 1 implementation.
DOMLSSerializerFilter provide applications the ability to examine nodes as they are being serialized.
DOMLSSerializerFilter lets the application decide what nodes should be serialized or not.