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> wrote:
> > <script> somefunction ( ) { code } </script>
> > ...
> > <span id="span1" onclick="somefunction()">The text</span>
> >
> > One could  use
> > <script id="somefunction"> {code} </script>
> > <listener observer="span1" event="click" handler ="#somefunction" />
> > ...
> > <span id="span1">The text</span>
>
> An unfortunate mechanism which does more to confuse script/content.  The
> current SVG proposals to extend XML Events at least addresses some of
this -
> but the DOM methods should be preferred, I don't see the motivation for
> having XML events at all.  DOM addEventListener should be preferred.
>
> >  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.

> > However being able to use statements like:
> >    b = 7;
> > without having to worry about unintended side effects is a nice benefit.
>
> Not really, a closure gives you that trivially, and the inability to share
> functions across is a much more significant problem.
>
> It seems to me that you're concerned with collisions between variables and
> mutations of  script elements, the first of which better script techniques
> can solve, the 2nd is simply not a problem with how scripts are defined in
> other XML based languages so I don't see why it should be in XHTML2.

If other XML languages have defined a standard for how self-
modifying scripts are handled, following that would be fine by me.
The point there was that  I don't see such a standard included either
directly in the XHTML2 standard or indirectly from some other
document.  It makes little difference to me what the standard is
for handling self-modifying code, so long as there is a standard.

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.  However suppose that an author
wishes merely to use two separate script packages with defined interfaces.
Even with the interfaces defined so that they don't interfere with each
other,
the supporting variables and functions could still clobber each other
because of the lack of modularity.

Objects can if properly used limit such problems.
The problem is then that one supposes that the code will be
well written and maintained.  Allowing independence of
execution with each <script> using its a separate global object
would eliminate that concern far more comprehensively
that mere good coding practice ever could.

Switching to this model will require considerable change
in coding practice.  However moving to a model that is similar
to separate compilation in programming is a good thing,
but the portion equivalent to the linker needs to be improved
before it is readily usable.  Rather than just tossing it all out
I'd like to see if it can be improved.

Received on Sunday, 14 March 2004 19:12:41 UTC