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

> [Original Message]
> From: Victor Kapustin <vak@mail.nw.ru>
>
> Ernest Cline wrote:
> > Well, first off, for XML documents, which also includes XHTML,
> > the entire document including gets parsed and loaded before
> > any scripts are run, so if I am understanding this correctly, no scripts
> > should be running before the document finishes loading.  (Note: This
> > is not the case for HTML)
> Agreed. One can adopt this policy for HTML scripting also. But it could be
> impractical from usability point of view (see further).
>
> > Also, if I understand the XHTML2/
> > XMLEvents model correctly., each script is self-contained so that
> > the creation, deletion, or editing of other <script> elements should
> > have no effect upon the script itself.
>
> Do not agree. The hosting environment (either a user agent or host
language
> or both) may allow different scripts to communicate (say, call functions).
> From practical point of view one can collect a function library (say, ten
> thousand lines of javascript) in one script while keeping event listeners
> scattered among many small scripts.

First off, if am understanding things correctly, scripting acts differently
in
XHTML2 than in HTML.

The interaction you describe isn't impossible in the XHTML2 model,
but it is done differently and through the DOM using XMLEvents if I am
understanding the specs correctly.  Giving scripts independence has
its advantages.  It would be nice to be able to include scripts from
different sources and not have to worry about the scripts interacting
by accident.  On the other hand, avoiding having to go thru the DOM 
to enable calling library functions would be nice.  Perhaps using an
"include" attribute?

I.e.,, something like this: (type="text/x-javascript"  left out for space)

<script id="lib" src="library.js" declare="declare" />
<script id="init" src="init.js" include="lib" />
<script id="button" src="button.js" include="lib" declare="declare" />

So that both the script in init and the script in button could incorporate
the library functions in lib and yet not have to worry that they interfere
with each other.  (AFAIK, there is no include capability in ECMAScript.)

> > The only fly in the ointment is
> > what if the script tries to modify the node which contains the script?
> [skipped]
> > On the other hand, self-modifying code is implementable,
> > with the original script being kept until it finishes execution,
> > but that would leave phantom nodes inaccessible via the
> > DOM and which could greatly complicate an implementation.
> Please comment on phantom nodes.

Suppose.a script modifies the node in the DOM that includes that
script.  If that is permitted then the script should be allowed to continue
to execute, yet the script is no longer accessible via the DOM.  That
is why I called such a node a "phantom node".  It continues to exist
for at least as long as the script inside continues to execute, yet it no
longer is part of the DOM for that document.

> Script modifying a script node is just one problem deserving a
> discussion, but not the only one.
>
> The other one is script collection initialization. The historical practice
> is to prefetch some [unparsed] entities (like images) by scripts WHILE
> the document is being loaded, so when onload event has been fired,
> all the stuff is here - the scripts are ready to process events
immediately,
> not waiting for dragging needed resources referred with URLs.
>
> I just tried to extend the idea to the scripts themselves: I have an
> alternative either to pollute a document with as many script elements as
> needed or permit the scripts to load function libraries (as separate
> scripts) they are dependent on (keeping track on what has already been
> loaded in some single script that every script is able to communicate).

The declare attribute (defer in HTML 4/ XHTML 1) does allow for scripts
to wait until they have been called to be actually loaded.  The old HTML
specification certainly assumes a universal scripting scope,
but there are some real advantages to limiting scope to just the one
<script> element (plus any other elements that are explicitly included)
and it would not cause any problems beyond making some of the
usages of javascript: URL's obsolete (Unfortunately, they could be
rewritten to work with the new model.)

Even have I misread the spec and this were not the intent, changing
to such a scripting model would give XHTML2 something it currently
lacks, a capability that could not be emulated using the existing
XHTML1 with XForms and XML Events added in as usual for
multi-namespace XML documents.  I think adding the robustness
of being able to use multiple script sources without having to worry
about unintended side effects is a good thing.

Received on Monday, 8 March 2004 16:58:25 UTC