[
Lists Home |
Date Index |
Thread Index
]
- From: Paul Prescod <papresco@technologist.com>
- To: "Xml-Dev (E-mail)" <xml-dev@ic.ac.uk>
- Date: Mon, 20 Oct 1997 10:11:21 -0400
Simon St.Laurent wrote:
> Scripts have been 'componentizable' for several years now through the SRC
> attribute of the SCRIPT element.
Not true. Componentization requires a separate namespace, setter and
getter functions, display area management, function name conventions and
so forth. Javascript has never had this before. Scriptlets are
Javascript applets. They add the conventions of java.applet to scripts.
> 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.
Not true. Java applets are "100% script scriptlets" written in Java.
Luckily we can approach this question emperically. Microsoft has four
sample scriptlets on ther website. The ratio of HTML to Javascript in
each of them is exteremely low. The HTML that is provided is typically
boilerplate:
They typically have a mostly vacuous header:
"
<html> <head>
<title>Label Scriptlet</title>
<STYLE>
</STYLE>
<script language="JavaScript">
<!--
"
a hell of a lot of JavaScript code, and then a placeholder DIV element.
One example explicitly downplays the importance of the div element:
<!--
***********************************************************************************
This is just a div tag. Properties are set in script, above.
***********************************************************************************
-->
There are *no* examples of "rich combinations of markup and script."
They are massively "script heavy". The only reason they must be embedded
in HTML is as a gesture of backwards compatibility and because
Javascript is so limited in its display model (i.e. it has none). There
is no good reason that these scriptlets would ever have to be updated to
XML. In fact, it would be a step backwards. HTML provides scripts with
display capabilities. XML cannot because XML has no formatting
semantics. You would have to add a stylesheet to your scriptlet (which
is pretty silly, IMO).
Note that I don't really mind that these Scriptlet things being in HTML,
and wouldn't much care if they were in XML. The important thing is that
they explicitly *separate* from the document itself. They can be dragged
and dropped in a WYSWIYG editor as if they were GIFs, PDFs or some other
black box format. They can be ignored by search engines. They can be
ignored by corporate text indexers. In other words, they help us to reap
the benefits of separating out the processing from our documents. The
percentage of HTML documents with scripts in them should *drop* because
of scriptlets and the percentage of XML documents with scripts in them
will probably always be low.
> Scriptlets may well have to be formatted for print and
> added to TOCs in certain situations.
Scriplets will not be formatted for print using the same processes that
format documents (CSS, XSL). They will be treated as black boxes to be
rendered by the Active-X engine, like GIFs or PDFs. They will probably
only be added to TOCs when the TOC explicitly lists figures, but the
content for the TOC would be supplied in the calling document, not the
scriptlet. You wouldn't index "chemical viewer scriptlet" (the scriplets
generic name) but rather "the H2O molecule" (the name of a particular
call to the scriptlet, in the calling document).
> They aren't 'real documents' (however
> you want to define that), but they are considerably more than scripts.
That's highly debatable. By definition I can do anything that they can
do with document.write(). And I can do substantially more with Java.
> >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.
I acknowledged that it was changing drastically. That is in fact the nub
of my point: every new browser release moves towards providing tools for
separating out scripting from indexable, WYSIWYG editable, formattable
document content.
> 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.
But as long as markup is generated by scripts they *must* pay attention
to the script. That's why markup should *not* be generated by scripts.
> Structured indexing, not
> full-text indexing should be the indexing model for XML.
Not true. You need both. Search engines cannot be familiar with the
structure of every document type on the web.
> In the meantime, CDATA types for elements (or the lack thereof) are a more
> pressing issue.
It isn't a pressing issue for scripting because scripts will not be
embedded in XML documents as often as they are in HTML documents. More
important: it doesn't make sense to add more reliance on DTDs to XML at
this point. <![CDATA[ works for the common case of code samples ]]>
Paul Prescod
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|
