"Ernest Cline" <ernestcline@mindspring.com>
> > [Original Message]
> > From: Jim Ley <jim@jibbering.com>
> >
> > >  Interaction between the scripts would be possible via the DOM.
> >
> > By firing mutation events on some special case?
>
> One possibilty, altho not what I was thinking of.

So what were you thinking of? There's no obvious mechanism I can see.

> If other XML languages have defined a standard for how self-
> modifying scripts are handled, following that would be fine by me.

no, None of them allow self-modifying scripts, the script is executed once,
modifying the contents of a script element simply modifies the DOM, it does
not modify the script, see SVG or HTML for cites - Why is XHTML going to
change this?  This does make less sense with XML-Events - of course that's a
problem with XML-Events, fixing those would make more sense than introducing
a new method, incompatible with the rest of the world.  (I'd say get rid of
XML-Events entirely as they confuse script/markup as badly as the onFOO
attributes, but I understand other people do have good use cases for them.)

> As for variable collisions, it seems to me that you are assuming that
> a document author will also write the scripts that he uses and will be
> responsible for their maintenance.

No, not at all, it's trivial to use closures to prevent variable collision
entirely (although that can be a little inelegant to achieve entirely), If
you do not understand how to do this, I would encourage you to learn more
ecmascript! there are good tutorials about, see Richard Cornford, Douglas
Crockford and others (unfortunately I don't have urls to hand, I'm sure a
google or googlegroups search will turn up lots of good resources)
http://jan.kollhof.net/projects/js/oopjs/index.xhtml  is Jan Kollhof's
example - although as I noted he still uses some global variables, but that
is simply because it's ugly not to and generally unneccessary - if you were
writing a library for inclusion by the incompetent then you may go the whole
way to hide all but what you intended to be public.

> Switching to this model will require considerable change
> in coding practice.

Yet you've not provided any sensible motivation for the changes other than
it solves problems which I certainly don't believe existing.

Jim.