If the attribute has not been explicitly assigned a value, but has been declared in the DTD, it will exist and have that default. Only if neither the document nor the DTD specifies a value will the Attribute really be considered absent and have no value; in that case, querying the attribute will return null.

Attributes may have multiple children that contain their data. (XML allows attributes to contain entity references, and tokenized attribute types such as NMTOKENS may have a child for each token.) For convenience, the Attribute object's getValue() method returns the string version of the attribute's value.

Attributes are not children of the Elements they belong to, in the usual sense, and have no valid Parent reference. However, the spec says they _do_ belong to a specific Element, and an INUSE exception is to be thrown if the user attempts to explicitly share them between elements.

Note that Elements do not permit attributes to appear to be shared (see the INUSE exception), so this object's mutability is officially not an issue.

Note: The ownerNode attribute is used to store the Element the Attr node is associated with. Attr nodes do not have parent nodes. Besides, the getOwnerElement() method can be used to get the element node this attribute is associated with.

AttrImpl does not support Namespaces. AttrNSImpl, which inherits from it, does.

AttrImpl used to inherit from ParentNode. It now directly inherits from NodeImpl and provide its own implementation of the ParentNode's behavior. The reason is that we now try and avoid to always create a Text node to hold the value of an attribute. The DOM spec requires it, so we still have to do it in case getFirstChild() is called for instance. The reason attribute values are stored as a list of nodes is so that they can carry more than a simple string. They can also contain EntityReference nodes. However, most of the times people only have a single string that they only set and get through Element.set/getAttribute or Attr.set/getValue. In this new version, the Attr node has a value pointer which can either be the String directly or a pointer to the first ChildNode. A flag tells which one it currently is. Note that while we try to stick with the direct String as much as possible once we've switched to a node there is no going back. This is because we have no way to know whether the application keeps referring to the node we once returned.

The gain in memory varies on the density of attributes in the document. But in the tests I've run I've seen up to 12% of memory gain. And the good thing is that it also leads to a slight gain in speed because we allocate fewer objects! I mean, that's until we have to actually create the node...

To avoid too much duplicated code, I got rid of ParentNode and renamed ChildAndParentNode, which I never really liked, to ParentNode for simplicity, this doesn't make much of a difference in memory usage because there are only very few objects that are only a Parent. This is only true now because AttrImpl now inherits directly from NodeImpl and has its own implementation of the ParentNode's node behavior. So there is still some duplicated code there.

This class doesn't directly support mutation events, however, it notifies the document when mutations are performed so that the document class do so.

WARNING: Some of the code here is partially duplicated in ParentNode, be careful to keep these two classes in sync!