Scripting and XML

Paul Prescod papresco at
Mon Oct 20 07:21:58 BST 1997

Simon St.Laurent wrote:
> >I expect that a few years from now this convention of putting markup and
> >scripting cheek to cheek will have died out. It is just another face of
> >the logical markup vs. presentational markup war. The trend is from
> >inline to external, just as with presentation.
> I agree with you on presentation, but I'll argue quite heartily that scripting
> is becoming an integral part of content.

I agree with you. Two years ago formatting was becoming an "integral
part of content." Today we are extricating it. Hopefully it won't take
two years to do the same with scripting, but it might.
> Which _can_ be done remotely - but that isn't to say that remote control is
> always the best solution.  OOP ticked off a lot of people when it first
> appeared for suggesting that data and code might work better as a unit than as
> separate parts, and I suspect JavaScript (though it's hardly OO) is going to
> take knocks for a similar offense.  

Luckily, the situations are not analogous. When is the last time you
tried to full-text index a datastructure in your program? When is the
last time you tried to edit one in a WYSIWYG editor? The reason you want
to move proccessing (whether it is formatting, JavaScript, or whatever)
out of documents is because the more processing you have in your
document, the less useful it is to tools other than the one that the
processing is intended for. I can write a document like this:

document.write( "<TITLE>" )
document.write( "My document" )
document.write( "</TITLE>" )

But good luck indexing it properly! Have you ever done an AltaVista
search and got a hit like this:

16. JavaScript Games - MineSweeper
0) && (y1>=0) && (x1. =0) && (leftValue>=0)) markSquare (bottomValue,
leftValue) if ((topValue>=0) && (rightValue>=0)) openSquare(topValue,
rightValue) }.. - size 13K -
13-Aug-97 - English

This isn't just a bug. It's a natural consequence of putting processing
information in a document. The multipurpose usefulness of a document is
generally inversely proportional to the amount of processing hacks in

> I'm not completely sure where you're
> coming from declaring the "JavaScript 'model' is textual replacement" - while
> textual replacement is one part of the JavaScript toolset, it's hardly the
> only piece.

How can I, in Javascript/Netscape 4.0 change the value of a text element
in my document by ID or element type, rather than by "textual
replacement" of JavaScript code by HTML code? The JavaScript model for
building HTML documents is textual replacement, not structural assembly.
> As much as I hate to use them as an example, Microsoft's scriptlets are a
> strong step in the opposite direction of what you would like to see.
> Scriptlets combine a small amount of code and some markup to create an
> interface component that can be added easily to a page.  

Scriptlets allow the componentization of scripting code so that you can
put less of it in your actual document and more of it in external
scripts. That seems to me to be a step in the right direction. A
scriptlet is a document in name only -- really it is a JavaScript
applet. I have no problem with that. They aren't meant to be indexed,
edited in WYSIWYG editors, formatted for print, added to website table
of contents or any of the other things that we expect to do with real

> As I said before, we'll see what people actually do with the stuff soon
> enough.

Sure. And we'll see again what they decide to do after they have had
some more experience with the headaches of intermingling the two.

 Paul Presscod

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list