Re: ISSUE-66: should Documents that aren\'t being presented be required to have a null defaultView?

>> To summarize options:
>>
>> 1) Require any non-presented DocumentWindow to have a null defaultView.
>> 2) Allow a non-presented DocumentWindow to have any AbstractView or null as
>> the defaultView (essentially, we disclaim stating a requirement on
>> non-presented documents).
>> 3) Forbid any non-presented Document to implement DocumentWindow (seems too
>> restrictive).
> 
> I am strongly in favour of 3. If we don't do 3, we're going to have to 
> require a whole heck more than 1 -- we're going to have to special case 
> every single API that requires a rendering context.
> 
> I am extremely against not specifying this (option 2), as I am against 
> not specifying anything that authors could end up relying on.

The problems with 3 are:

* It doesn't allow transitions between presented and non-presented, this
   transition already happens today, and it would be bad to restrict new
   features such as allowing a document to become presented
   after-the-fact
* It means that implementations has to double the number of document
   classes.
* It means that the parser has to be aware of if the document is going
   to be presented or not.

So I think 1 is the way to go. Alternativly:

4) Require that the defaultView is not a Window (and, if we add it, 
parentWindow must be null).

/ Jonas