RE: Window object, very rough cut of proposed content for first version of spec


> I don't think anything in the spec requires having a UI. The 
> properties are about:
> 1) Providing a global scope for ES
> 2) methods for some aspects of walking the tree of document 
> references in a CDR situation (somewhat incomplete w/o window.frames)
> 3) timers
> 4) finding out the current document's URI and navigating to new URIs
> They would all work fine in non-visual UAs.

I understand, and my point was only about the name.

We have a system that uses JavaScript. It can load a document via one set of
interfaces, and then push that document to one or more renderers. I don't
fancy calling the global context 'window', since it is a 'controller' that
contains both the network interfaces and the renderers. But it would be good
if it had as many of the same methods and interfaces as possible as other

> I was referring mainly to other existing features that are 
> already widely implemented.

So one answer is that my architecture falls outside of what you are trying
to do. I obviously don't have a problem with that, insofar as you are
undertaking a tidying up exercise of documenting what exists. But insofar as
a 'standard' set of APIs is being defined for the future, I think it would
be better if my kind of application could also fall within this. 

> We could put timers on a separate interface. But I don't 
> think anything in the proposed interface is onerous to 
> implement or requires having a UI.

That's more the direction I was hoping for. It would be great if we could
base the interfaces we need for things like timers, and so on, on some



Mark Birbeck
CEO Ltd.

t: +44 (0) 20 7689 9232

Download our XForms processor from

Received on Tuesday, 14 February 2006 12:45:45 UTC