Re: XML Events : Should modification of the node containing a script be allowed?

> [Original Message]
> From: Jim Ley <jim@jibbering.com>
>
> "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 possibility, altho not what I was thinking of.
>
> So what were you thinking of?
> There's no obvious mechanism I can see.

What I had been thinking of was using the contents of <meta> elements
to store data between calls to various scripts which any script could then
use.  Inelegant, but doable and not violating the semantics of the <meta>
element at all.

> > 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 ...

No I understand completely.  For eliminating problems within a single
script package, closure is an excellent solution.  But what if a document
author wishes to use two script  packages that declare classes with
the same name?  Even with good coding practice including the use
of closure, this is a potential problem.  With separate script environments
the document author will never have to touch or even look at the code,
all he needs to know is how to call the intended script.  Whereas with
a common script environment he will also need to examine the packages
for potential conflicts and fix them if they exist.
(Or have someone do so for him) 

> > 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.

You seem to be assuming an authoring model where the author
crafts the document, the scripts, etc.  For expert authors who do it all,
its not unreasonable, but a document model that allows authors who
know nothing about scripting to be able to use pre-written scripts
from multiple sources without worrying about unintended side-effects
is a good thing.

Received on Sunday, 14 March 2004 19:05:27 UTC