I have left the DocumentElement without proposed changes mainly from following
reasons:

1) There is a need to have an ability to attach change listeners to the
DocumentElement-s. This kind of functionality is not provided by the
j.s.t.DocumentElement

2) It's common approach to better have final classes in the API that interfaces

3) This is not possible to extend (add a method) to the j.s.t.DocumentElement in
a future.

IMHO it would still be beneficial to implement Element by the final class (of
course only if the methods in the final class match those in the Element
interface) to give a notion what methods are in the class. But I don't have a
strong opinion regarding this.

OK. I will make the DocumentElement implement j.s.t.Element.

fixed - now the DocumentElement implements j.s.t.Element + has following
additional methods (which are either necessary or very usefull):

    public DocumentModel getDocumentModel();
    
    /** Returns a type of the element. */
    public String getType();
    
    /** Returns a list of children elements. */
    public List getChildren();
    
    /** Adds a DocumentElementListener to this DocumentElement instance */
    public void addDocumentElementListener(DocumentElementListener del);
    
    /** Removes a DocumentElementListener to this DocumentElement instance */
    public void removeDocumentElementListener(DocumentElementListener del);

Oops, I encountered a problem with the DocumentElement implementing
j.s.t.Element :-(.

In JDK1.5 following example is valid:

public class Main {
    public class XC implements X {
        public XC getX() {
            return (XC)null;
        }
    }
    public interface X {
        public X getX();
    }
}

The overriding method returns a supertype of the type declared in the overrided
method. However this does not work in JDK1.4. A possible solution would be to
return the original interface, but this would cause a need to recast the type in
many places.

So I am removing the changes - DocumentElement does not implement the Element
interface, though it has all its methods. 

I can fix this when we use 1.5 for the NB build.

Based on QE notification that the RESOLVED LATER state of issues should not be
used at all I am changing this issue to an NEW ENHANCEMENT (NEW DEFECT would
allegedly affect the statistics).

TM 5.0->TBD

This issue (as several others which I am changing at once) as a TCR or TCA, 
but it is not a defect. As I am aware of our attitude towards non-defects - 
e.g. ignore them, I believe it is safe to assume that these issues are never 
going to be fixed. As such I am closing them. If anyone believes that this 
issue is important to be fixed, then please reopen. In such case I suggest to 
track it then as a defect.