DOMDocument
DOMDocument is the main class for acessing XML documents. This class and all related DOMXxx-classes implement a subset of the DOM-Level-1 specification for XML parsers, adopted to the the SuperCollider language.
See http://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html for the full level 1 specification of the Document Object Model (DOM).
All interfaces specified by the DOM, if used at all in this implementation, are directly mapped to SuperCollider classes. The original interface inheritance hierarchy is thus preserved in the class hierarchy (which is not necessarily required for the implementation of interfaces, see DOM-Level-1, 1.1.2).
Classes implementing the DOM interfaces are:
DOMDocument
The central class for accessing XML documents. This is the only class whose instances get created using 'DOMDocument.new', instances of any other class are either created internally during parsing of an XML-string,
or programmatically through calls on 'DOMDocument.createElement(..)', 'DOMDocument.createText(..)', etc.
DOMElement
Represents an XML-tag.
DOMAttr
Represents an attribute of an XML-tag. The implementation considers this class as a helper class and only partially implements the DOM specification of DOMAttr. Attribute values should only be accessed via the corresponding getAttribute, setAttribute methods of DOMElement.
DOMCharacterData
Abstract class. This is the common superclass of all nodes in the document which carry free-form string content.
DOMText
Text in the document.
DOMComment
Comment in the document (ignored by default during parsing, set DOMDocument.parseComments=true to get access to comment nodes).
DOMCDATASection
Raw text section.
DOMProcessingInstruction
Processing instruction nodes.
DOMNode
The common superclass of all nodes. Each node can also be accessed via the
methods of this class only, which the DOM calls a 'flat'-access to the document
nodes (flat in terms of meta-model classes, the document-structure of course
is always composed of nodes in a tree structure described by the parent-children
relationship, see DOM-Level-1, 1.1.4).
Some interfaces specified in the DOM-Level-1 are not implemented by this adoption:
DOMString
Not implemented, SuperCollider's own String class is used for best integration into SuperCollider.
NodeList, NamedNodeMap
Not implemented, SuperCollider's own collection classes are used for best integration into SuperCollider.
DOMException
Not implemented, in most cases errors will result from SuperCollider's own exception handling, especially in cases of errors resulting from collection classes. Parse errors are handled by method DOMDocument.parseError which by default will simply output a text message and exit the program. This might be overwritten for a more subtle handling of parse errors.
DOMDocumentType, DOMNotation
Not implemented. DTDs are no longer up-to-date technology anyway (use XML-Schema instead), and in most cases it will not be necessary to validate an XML document from within SuperCollider. External tools could easily be used in cases where DTD-based validation is required. Calling DOMDocument.getDoctype will always return nil (as allowed by the specification, see DOM-Level-1, 1.3). During parsing, doctype declarations will be treated like comments.
DOMEntity, DOMEntityReference
Not implemented, only a fixed set of simple character-entities in Text-nodes is supported.
As a notation convention, all methods marked as 'public' ('+') in the UML class diagram belong to the implementations of DOM interfaces. In contrast to that, all methods marked as 'friendly' ('~') are additions specific to this SuperCollider-implementations. The code generated from the class diagram does, however, not distinguish between different levels of visibility, so the 'friendly' methods are still publicly accessibly from any other SuperCollider class. (There are also methods marked as 'protected' ('#'), these are intended to be internal
methods of the implementation. They should not be called from outside code.)
Note: The DOM-Level-1 specification covers version 1.0 of the XML standard only. Newer versions of the DOM also include features like XML namespaces, which are explicitly not supported by this adoption, but might not be required for most applications within SuperCollider anyway.