Scripting and XML

[Simon St.Laurent]

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

Scripts have been 'componentizable' for several years now through the SRC 
attribute of the SCRIPT element. Scriptlets are not about componentizing 
JavaScript - they are about componentizing rich combinations of markup and 
script.  While you could write a scriptlet in 100% script, you'd probably be 
wasting your time.  Scriptlets may well have to be formatted for print and 
added to TOCs in certain situations.  They aren't 'real documents' (however 
you want to define that), but they are considerably more than scripts.

----------------------------------

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

This is changing drastically.  It's a piece of cake in JavaScript/Internet 
Explorer 4.0, at least for the ID.  

<SPAN ID="changeme">The contents of this material are subject to 
change.</SPAN>

<SCRIPT LANGUAGE="JavaScript">
document.all["changeme"].innertext="The formatting of this material is subject 
to change.";
document.all.changeme.innerHTML="The <I>formatting</I> is subject to change.";
document.all.changeme.style.display="none"; //makes it invisible
document.all.changeme.style.fontSize=50;
document.all.changeme.style.display=""; //makes it visible again
changeme.outerHTML="<SPAN ID="newelement">This is new material</SPAN>";
document.all.newelement.style.fontWeight="bold";
</SCRIPT>

This is not a real application, obviously, and I haven't checked the code, but 
you get the idea of some of the things that are possible.  Addressing elements 
by ID is a piece of cake - and much cleaner than document.write().  While the 
examples above are pretty useless hacks, in combination they can produce 
industrial-strength interfaces.  (Microsoft of course did Asteroids, but it 
has considerable _practical_ use for creating client-side applications.)  XML 
offers even more advantages to live pages than it does to static, providing a 
far more useful structure on which to build than HTML.

I'm hoping that the W3C figures out the element type end of this and makes it 
more useful for XML.  JavaScript may have begun as a hack, but it still has 
considerable strength.

---------------------------

>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) }..
> http://www.geocities.com/Wellesley/2159/minesweeper.html - size 13K -
>13-Aug-97 - English

XML should take care of this indexing issue, if the search engine developers 
simply tell their machines to ignore the content of SCRIPT tags.  They could 
have done this with HTML, but chose to ignore markup intead. When they update 
to XML, they'll be paying more attention to markup.  Structured indexing, not 
full-text indexing should be the indexing model for  XML.

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

It sounds like one of us has some severe static in his crystal ball.  We can 
sort out which one of us it is in a few years.

In the meantime, CDATA types for elements (or the lack thereof) are a more 
pressing issue.

Simon St.Laurent
Dynamic HTML: A Primer


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