If the base element defines a view of a derived element, then this view is well defined for any derived type, and should conform to the declaration of the base class. All I am saying is that a base type inherently defines a view of the derived type, and that this view may be used to parse information from derived types. The use of views in this paper is extremely limited. It is extremely useful to allow views of a document based on an XML query language - this would be analogous to the use of views in relational databases. That is a topic for another paper, but I want to be clear that I am not proposing that the use of views for understanding inheritance in this paper be seen as a general model for views.
Views allow lexical recognition and inheritance to coexist.
If we say that a Square is a Shape, then we also require that the Shape view of a Square be a valid Shape according to the definition of Shape in the schema. Frequently, however, the derived type may have its own name for content inherited from a base type. If any element of Shape were missing, the declaration of Square would be invalid. When an element is declared with another element type as its basis, the declaration of the derived element is invalid if it fails to specify every member of the base element. This is important, since the base element view of any element belonging to the derived element must be well defined.