An interface to an object that is able to build, or augment, a DOM tree from various input sources.
LSParser provides an API for parsing XML and building the
corresponding DOM document structure. A
can be obtained by invoking the
As specified in [DOM Level 3 Core] , when a document is first made available via the LSParser:
- there will never be two adjacent nodes of type NODE_TEXT, and there will never be empty text nodes.
- it is expected that the
nodeValueattributes of an
Attrnode initially return the XML 1.0 normalized value. However, if the parameters " 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 parameters " datatype-normalization" is set to
false, the XML 1.0 attribute normalization is guaranteed to occur, and if the attributes list does not contain namespace declarations, the
Elementnode represents the property [attributes] defined in [XML Information Set] .
LSParser objects are expected to also
events::EventTarget interface so that event
listeners can be registered on asynchronous
Events supported by asynchronous
LSParser objects are:
LSParserfinishes to load the document. See also the definition of the
LSParsersignals progress as data is parsed. This specification does not attempt to define exactly when progress events should be dispatched. That is intentionally left as implementation-dependent. Here is one example of how an application might dispatch progress events: Once the parser starts receiving data, a progress event is dispatched to indicate that the parsing starts. From there on, a progress event is dispatched for every 4096 bytes of data that is received and processed. This is only one example, though, and implementations can choose to dispatch progress events at any time while parsing, or not dispatch them at all. See also the definition of the
Note: All events defined in this specification use the
While parsing an input source, errors are reported to the application
through the error handler (
error-handler" parameter). This specification does in no way try to define all possible
errors that can occur while parsing XML, or any other markup, but some
common error cases are defined. The types (
errors and warnings defined by this specification are:
- Raised if the parameter " check-character-normalization" is set to true and a string is encountered that fails normalization checking.
- Raised if the
configuration parameter "disallow-doctype" is set to
trueand a doctype is encountered.
Raised when loading a document and no input is specified in the
- Raised if a processing
instruction is encountered in a location where the base URI of the
processing instruction can not be preserved. One example of a case where
this warning will be raised is if the configuration parameter "
entities" is set to
falseand the following XML file is parsed:
<!DOCTYPE root [ <!ENTITY e SYSTEM 'subdir/myentity.ent' ]> <root> &e; </root>And
<one> <two/> </one> <?pi 3.14159?> <more/>
implementation dependent warning that may be raised if the configuration
namespaces" is set to
trueand an unbound namespace prefix is encountered in an entity's replacement text. Raising this warning is not enforced since some existing parsers may not recognize unbound namespace prefixes in the replacement text of entities.
- Raised if the
configuration parameter "ignore-unknown-character-denormalizations" is
falseand a character is encountered for which the processor cannot determine the normalization properties.
- Raised if an unsupported encoding is encountered.
Raised if the configuration parameter "supported-media-types-only" is set
trueand an unsupported media type is encountered.
In addition to raising the defined errors and warnings, implementations are expected to raise implementation specific errors and warnings for any other error and warning cases such as IO errors (file not found, permission denied,...), XML well-formedness errors, and so on.