xmlDOM.cls File Reference

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)).

valid - A string containing the valid characters for a XML name

xmlDOM.cls line 1868 "if name~verify(xmlValidName())>0 "
xmlDOM.cls line 1901 "if qualifiedName~verify(xmlValidName())>0 "
xmlDOM.cls line 2221 "if name~verify(xmlValidName())>0"
xmlDOM.cls line 2255 "if qualifiedName~verify(xmlValidName())>0"
xmlDOM.cls line 2317 "if tagName~verify(xmlValidName())>0"
xmlDOM.cls line 2346 "if qualifiedName~verify(xmlValidName())>0"
xmlDOM.cls line 2387 "if target~verify(xmlValidName())>0"
xmlDOM.cls line 2615 "if qualifiedName~verify(xmlValidName())>0"

Definition at line 53 of xmlDOM.cls

Generates a "under construction" message for things not yet operational.

name - The name of the thing the message is about
message - The message text

xmlDOM.cls line 1649 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2203 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2376 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2459 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2510 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2532 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2575 "raise syntax 93.900 array (isUnderConstruction(.context~name))"
xmlDOM.cls line 2661 "raise syntax 93.900 array (isUnderConstruction(.context~name))"

Definition at line 61 of xmlDOM.cls

xmlDomString is a subclass of String, for the time being without any modifications.


Definition at line 68 of xmlDOM.cls

xmlDomTimeStamp represents a number of milliseconds


Definition at line 72 of xmlDOM.cls

xmlDomUserData represents a reference to application data.


Definition at line 76 of xmlDOM.cls

xmlDomObject represents an object reference.


Definition at line 80 of xmlDOM.cls

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
NodeList.

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

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
xmLNode.

The items in the xmlNodeList are accessible via an integral index, starting from 0.


Definition at line 207 of xmlDOM.cls

CLASS: xmlNode

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

A convenience constant to implement null


Definition at line 299 of xmlDOM.cls

Constants that define the type of nodes that are possible.


Definition at line 303 of xmlDOM.cls

Definition at line 304 of xmlDOM.cls

Definition at line 305 of xmlDOM.cls

Definition at line 306 of xmlDOM.cls

Definition at line 307 of xmlDOM.cls

Definition at line 308 of xmlDOM.cls

Definition at line 309 of xmlDOM.cls

Definition at line 310 of xmlDOM.cls

Definition at line 311 of xmlDOM.cls

Definition at line 312 of xmlDOM.cls

Definition at line 313 of xmlDOM.cls

Definition at line 314 of xmlDOM.cls

CLASS: xmlNamedNodeMap

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

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
attribute's value(s).

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
discussion).


Definition at line 1111 of xmlDOM.cls

CLASS: xmlCharacterData

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

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

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

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
well-formed XML.

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

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

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:

• entities - This is a xmlNamedNodeMap giving the definitions of external and internal entities. For entity names
  defined more than once, only the first definition is provided (others are ignored as required by the XML
  recommendation). This may be .nil if the information is not provided by the parser, or if no entities are
  defined.


• internalSubset - A string giving the complete internal subset from the document. This does not include the
  brackets which enclose the subset. If the document has no internal subset, this is .nil.


• name - The name of the root element as given in the DOCTYPE declaration, if present.


• notations - This is a xmlNamedNodeMap giving the definitions of notations. For notation names defined more than
  once, only the first definition is provided (others are ignored as required by the XML recommendation). This may be
  .nil if the information is not provided by the parser, or if no notations are defined.


• publicId - The public identifier for the external subset of the document type definition. This will be a string
  or .nil.


• systemId - The system identifier for the external subset of the document type definition. This will be a URI as a
  string, or .nil.

DOM Level 3 doesn't support editing DocumentType nodes. DocumentType nodes are read-only.


Definition at line 1514 of xmlDOM.cls

CLASS: xmlElement

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

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

The xmlDomImplementation interface provides a number of methods for performing operations that are independent of any
particular instance of the document object model.


Definition at line 2584 of xmlDOM.cls

CLASS: domBuilder




Definition at line 2706 of xmlDOM.cls

CLASS: xmlParser

A non-validating simple XML parser. The parser recognizes the following:

• Document start, when a XML file has been stringified and when the parseSting method has accepted the
  string.


• XML Comments, no test for not allowed comment nesting.


• Removable White Space is removed when encountered.


• Processing Instructions (PI's), split into target (e.g. xml in <?xml version....?>) and data.


• CDATA with it's raw unparsed text.


• Attribute only tags, with their parsed, but without namespace checking, attributes.


• Tags with atributes as above and their parsed (i.e. resolved entities) text content.


• Document end, when the end of the XML string has been reached.

Definition at line 2882 of xmlDOM.cls