Entity nodes hold the reference data for an XML Entity -- either
parsed or unparsed. The nodeName (inherited from Node) will contain
the name (if any) of the Entity. Its data will be contained in the
Entity's children, in exactly the structure which an
EntityReference to this name will present within the document's
Note that this object models the actual entity, _not_ the entity
declaration or the entity reference.
An XML processor may choose to completely expand entities before
the structure model is passed to the DOM; in this case, there will
be no EntityReferences in the DOM tree.
Quoting the 10/01 DOM Proposal,
"The DOM Level 1 does not support editing Entity nodes; if a user
wants to make changes to the contents of an Entity, every related
EntityReference node has to be replaced in the structure model by
a clone of the Entity's contents, and then the desired changes
must be made to each of those clones instead. All the
descendants of an Entity node are readonly."
I'm interpreting this as: It is the parser's responsibilty to call
the non-DOM operation setReadOnly(true,true) after it constructs
the Entity. Since the DOM explicitly decided not to deal with this,
_any_ answer will involve a non-DOM operation, and this is the
NON-DOM The public identifier associated with the entity. If not specified,
this will be null.
public void setSystemId(java.lang.String id)
NON-DOM The system identifier associated with the entity. If not
specified, this will be null.
public void setNotationName(java.lang.String name)
NON-DOM Unparsed entities -- which contain non-XML data -- have a
"notation name" which tells applications how to deal with them.
Parsed entities, which are in XML format, don't need this and
set it to null.