|::routine xmlValidName public|
XML name valid characters. For (oo)Rexx, which only supports ASCII at the moment the valid range is alpha (lower and
upper) and digits, plus '.', '-', '_' and' :' (this last one for qualified names (i.e. namespace:tag)).
|::routine isUnderConstruction public|
Generates a "under construction" message for things not yet operational.
|::class xmlDomString public subclass string|
|::class xmlDomTimeStamp public subclass string|
|::class xmlDomUserData public|
|::class xmlDomObject public|
|::class domException public|
domExceptions and their codes.
DOM operations only raise exceptions in "exceptional" circumstances, i.e., when an operation is impossible to perform
(either for logical reasons, because data is lost, or because the implementation has become unstable). In general, DOM
methods return specific error values in ordinary processing situations, such as out-of-bound errors when using
Implementations should raise other exceptions under other circumstances. For example, implementations should raise an
implementation-dependent exception if a .nil argument is passed when null was not expected.
Some languages and object systems do not support the concept of exceptions. For such systems, error conditions may be
indicated using native error reporting mechanisms. For some bindings, for example, methods may return error codes
similar to those listed in the corresponding method descriptions.
Definition at line 98 of xmlDOM.cls
|::class xmlNodeList public|
The xmlNodeList interface provides the abstraction of an ordered collection of xmlNodes, without defining or
constraining how this collection is implemented. xmlNodeList objects in the DOM are live.
For this ooRexx implementation a xmlNodeLIst is defined as a resticted array, whose members must be an instance of
The items in the xmlNodeList are accessible via an integral index, starting from 0.
Definition at line 207 of xmlDOM.cls
|::class xmlNode public|
The xmlNode class is the base class for real nodetypes such as elementNode and textNode.
Methods that make no sense or that are just plain impossible to implement in this base class, because the
implementation is only possible in a subclass will raise syntax error 93.963 - Unsupported or not implented method.
Methods that have a default value (e.g. .nil) will be intialized to that default value and need to be overridden in
the appropiate subclass.
Definition at line 295 of xmlDOM.cls
|::constant elementNode 1|
|::class xmlNamedNodeMap public|
Objects implementing the xmlNamedNodeMap interface are used to represent collections of nodes that can be accessed by
name. Note that xmlNamedNodeMap does not inherit from NodeList; NamedNodeMaps are not maintained in any particular
order. Objects contained in an object implementing xmlNamedNodeMap may also be accessed by an ordinal index, but this
is simply to allow convenient enumeration of the contents of a xmlNamedNodeMap, and does not imply that the DOM
specifies an order to these xmlNodes. xmlNamedNodeMap objects in the DOM are live.
Definition at line 897 of xmlDOM.cls
|::class xmlAttr public subclass xmlNode|
The xmlAttr interface represents an attribute in an xmlElement object. Typically the allowable values for the
attribute are defined in a schema associated with the document.
xmlAttr objects inherit the xmlNode interface, but since they are not actually child nodes of the element they
describe, the DOM does not consider them part of the document tree. Thus, the xmlNode attributes parentNode,
previousSibling, and nextSibling have a .nil value for xmlAttr objects. The DOM takes the view
that attributes are properties of elements rather than having a separate identity from the elements they are
associated with; this should make it more efficient to implement such features as default attributes associated with
all elements of a given type. Furthermore, xmlAttr nodes may not be immediate children of a xmlDocumentFragment.
However, they can be associated with xmlElement nodes contained within a xmlDocumentFragment. In short, users and
implementors of the DOM need to be aware that xmlAttr nodes have some things in common with other objects inheriting
the Node interface, but they also are quite distinct.
The attribute's effective value is determined as follows: if this attribute has been explicitly assigned any value,
that value is the attribute's effective value; otherwise, if there is a declaration for this attribute, and that
declaration includes a default value, then that default value is the attribute's effective value; otherwise, the
attribute does not exist on this element in the structure model until it has been explicitly added. Note that the
xmlNode nodeValue attribute on the xmlAttr instance can also be used to retrieve the string version of the
If the attribute was not explicitly given a value in the instance document but has a default value provided by the
schema associated with the document, an attribute node will be created with specified set to false. Removing attribute
nodes for which a default value is defined in the schema generates a new attribute node with the default value and
specified set to false. If validation occurred while invoking the xmlDocument normalizeDocument, attribute
nodes with specified equals to false are recomputed according to the default attribute values provided by the schema.
If no default value is associate with this attribute in the schema, the attribute node is discarded.
In XML, where the value of an attribute can contain entity references, the child nodes of the xmlAttr node may be
either xmlText or xmlEntityReference nodes (when these are in use; see the description ofxml EntityReference for
Definition at line 1111 of xmlDOM.cls
|::class xmlCharacterData public mixinclass xmlNode|
The CharacterData interface extends xmlNode with a set of attributes and methods for accessing character data in the
DOM. For clarity this set is defined here rather than on each object that uses these attributes and methods. No DOM
objects correspond directly to CharacterData, though Text and others do inherit the interface from it. All offsets in
this interface start from 0.
The following DOES NOT APPLY FOR this ooRexx xmlDOM implementation. Characters are ASCII 8-bit.
As explained in the DOMString interface, text strings in the DOM are represented in UTF-16, i.e. as a sequence of
16-bit units. In the following, the term 16-bit units is used whenever necessary to indicate that indexing on
CharacterData is done in 16-bit units.
Definition at line 1198 of xmlDOM.cls
|::class xmlComment public subclass xmlNode inherit xmlCharacterData|
This interface inherits from xmlCharacterData and represents the content of a comment, i.e., all the characters
between the starting ''. Note that this is the definition of a comment in XML, and, in practice,
HTML, although some HTML tools may implement the full SGML comment structure.
No lexical check is done on the content of a comment and it is therefore possible to have the character sequence "--"
(double-hyphen) in the content, which is illegal in a comment per section 2.5 of [XML 1.0]. The presence of this
character sequence must generate a fatal error during serialization.
Definition at line 1288 of xmlDOM.cls
|::class xmlText public subclass xmlNode inherit xmlCharacterData|
The XMLText interface inherits from XMLCharacterData and represents the textual content (termed character data in XML)
of an xmlElement or xmlAttr. If there is no markup inside an element's content, the text is contained in a single
object implementing the xmlText interface that is the only child of the element. If there is markup, it is parsed into
the information items (elements, comments, etc.) and xmlText nodes that form the list of children of the element.
When a document is first made available via the DOM, there is only one xmlText node for each block of text. Users may
create adjacent xmlText nodes that represent the contents of a given element without any intervening markup, but
should be aware that there is no way to represent the separations between these nodes in XML or HTML, so they will not
(in general) persist between DOM editing sessions. The xmlNode normalize method merges any such adjacent
xmlText objects into a single node for each block of text.
No lexical check is done on the content of a xmlText node and, depending on its position in the document, some
characters must be escaped during serialization using character references; e.g. the characters "<&" if the textual
content is part of an element or of an attribute, the character sequence "]]>" when part of an element, the quotation
mark character " or the apostrophe character ' when part of an attribute.
Definition at line 1317 of xmlDOM.cls
|::class xmlCDATASection public subclass xmlText|
CDATA sections are used to escape blocks of text containing characters that would otherwise be regarded as markup.
The only delimiter that is recognized in a CDATA section is the "]]>" string that ends the CDATA section. CDATA
sections cannot be nested. Their primary purpose is for including material such as XML fragments, without needing to
escape all the delimiters.
The xmlCharacterData data attribute holds the text that is contained by the CDATA section. Note that this may
contain characters that need to be escaped outside of CDATA sections and that, depending on the character encoding
("charset") chosen for serialization, it may be impossible to write out some characters as part of a CDATA section.
The CDATASection interface inherits from the xmlCharacterData interface through the xmlText interface. Adjacent
xmlCDATASection nodes are not merged by use of the normalize method of the xmlNode interface.
No lexical check is done on the content of a CDATA section and it is therefore possible to have the character sequence
"]]>" in the content, which is illegal in a CDATA section per section 2.7 of [XML 1.0]. The presence of this character
sequence must generate a fatal error during serialization.
Note: Because no markup is recognized within a xmlCDATASection, character numeric references cannot be used as an
escape mechanism when serializing. Therefore, action needs to be taken when serializing a CDATASection with a
character encoding where some of the contained characters cannot be represented. Failure to do so would not produce
One potential solution in the serialization process is to end the CDATA section before the character, output the
character using a character reference or entity reference, and open a new CDATA section for any further characters in
the text node. Note, however, that some code conversion libraries at the time of writing do not return an error or
exception when a character is missing from the encoding, making the task of ensuring that data is not corrupted on
serialization more difficult.
Definition at line 1440 of xmlDOM.cls
|::class xmlPI public subclass xmlNode|
The ProcessingInstruction interface represents a "processing instruction", used in XML as a way to keep
processor-specific information in the text of the document.
No lexical check is done on the content of a processing instruction and it is therefore possible to have the character
sequence "?>" in the content, which is illegal a processing instruction per section 2.6 of [XML 1.0]. The presence of
this character sequence must generate a fatal error during serialization.
Definition at line 1460 of xmlDOM.cls
|::class xmlDocumentType public subclass xmlNode|
Information about the notations and entities declared by a document (including the external subset if the parser uses
it and can provide the information) is available from a xmlDocumentType object. The xmlDocumentType for a document is
available from the xmlDocument objectís doctype attribute; if there is no DOCTYPE declaration for the document, the
documentís doctype attribute will be set to .nil instead of an instance of this interface.
xmlDocumentType is a subclass (precisation) of xmlNode, and adds the following attributes:
|::class xmlElement public subclass xmlNode|
The Element interface represents an element in an HTML or XML document. Elements may have attributes associated with
them; since the Element interface inherits from Node, the generic Node interface attribute attributes may be used to
retrieve the set of all attributes for an element. There are methods on the Element interface to retrieve either an
Attr object by name or an attribute value by name. In XML, where an attribute value may contain entity references, an
Attr object should be retrieved to examine the possibly fairly complex sub-tree representing the attribute value. On
the other hand, in HTML, where all attributes have simple string values, methods to directly access an attribute value
can safely be used as a convenience.
Note: In DOM Level 2, the method normalize is inherited from the Node interface where it was moved.
Definition at line 1582 of xmlDOM.cls
|::class xmlDocument public subclass xmlNode|
The xmlDocument interface represents the entire HTML or XML document. Conceptually, it is the root of the document
tree, and provides the primary access to the document's data.
Since elements, text nodes, comments, processing instructions, etc. cannot exist outside the context of a Document,
the xmlDocument interface also contains the factory methods needed to create these objects. The xmlNode objects
created have a ownerDocument attribute which associates them with the Document within whose context they were created.
Definition at line 2036 of xmlDOM.cls
|::class xmlDomImplementation public|
|::class xmlParser public|
A non-validating simple XML parser. The parser recognizes the following:
|Generated on 30 Jul 2015 13:57:00 for xmlDOM for OOrexx by 0.0.1|