An XML document as internalized into a logical tree structure.
SDK
- macOS 10.4+
Framework
- Foundation
Declaration
class XMLDocument : XMLNode
Overview
An XMLDocument
object can have multiple child nodes but only one element, the root element. Any other node must be a XMLNode
object representing a comment or a processing instruction. If you attempt to add any other kind of child node to an XMLDocument
object, such as an attribute, namespace, another document object, or an element other than the root, XMLDocument
raises an exception. If you add a valid child node and that object already has a parent, XMLDocument
raises an exception. An XMLDocument
object may also have document-global attributes, such as XML version, character encoding, referenced DTD, and MIME type.
The initializers of the XMLDocument
class read an external source of XML, whether it be a local file or remote website, parse it, and process it into the tree representation. You can also construct an XMLDocument
programmatically. There are accessor methods for getting and setting document attributes, methods for transforming documents using XSLT, a method for dynamically validating a document, and methods for printing out the content of an XMLDocument
as XML, XHTML, HTML, or plain text.
The XMLDocument
class is thread-safe as long as any given instance is used only in one thread.
Subclassing Notes
Methods to Override
To subclass NSXMLDocument
you need to override the primary initializer, init(data:
, and the methods listed below. In most cases, you need only invoke the superclass implementation, adding any subclass-specific code before or after the invocation, as necessary.
By default NSXMLDocument
implements the NSObject
is
method to perform a deep comparison: two NSXMLDocument
objects are not considered equal unless they have the same name, same child nodes, same attributes, and so on. The comparison does not consider the parent node (and hence the node’s location). If you want a different standard of comparison, override is
.
Special Considerations
Because of the architecture and data model of NSXML, when it parses and processes a source of XML it cannot know about your subclass unless you override the class method replacement
to return your custom class in place of an NSXML
class. If your custom class has no direct NSXML
counterpart—for example, it is a subclass of NSXMLNode
that represents CDATA sections—then you can walk the tree after it has been created and insert the new node where appropriate.