Lists Home |
Date Index |
- From: "Simon St.Laurent" <SimonStL@classic.msn.com>
- To: "Xml-Dev (E-mail)" <firstname.lastname@example.org>
- Date: Sun, 19 Oct 97 13:16:48 UT
This responds to a lot of the excellent points brought up by various authors
in the last twelve hours.
>The question is, do you regard your script as part of the document
>or not? If so, you should use <![CDATA[. If not, the PI is perfectly
>appropriate and being used exactly as designed. -Tim
Coming from the HTML world, I do regard the script as an integral part of the
document. Many web developers are now creating documents that require scripts
to be meaningful. Unfortunately, <![CDATA[ seems like an extraordinary kludgy
solution to a very simple problem, and one which is likely to crop up in a
very high proportion of documents. Fortunately, ]]> is not a sequence that
should appear in too many ECMAScript documents.
PIs feel like calls to external processing for me - while it is possible to
describe the scripting engine as an external processor, this doesn't recognize
the growing importance of documents that carry internal code. The word
'document' has received some heavy redefinition on the web in the last year,
with more changes coming every day. 'Live' content is becoming more and more
common - inside the HTML document as well as in the process generating it.
At present, most SCRIPT tags in use on the Internet already have to hide their
code inside comments to avoid spilling their contents across the screens of
older browsers. This just seems to add an extra layer of detritus to scripts.
While it's workable, it doesn't seem like an elegant way to interoperate with
another key set of web standards. As scripting and markup grow more and more
intertwined (i.e., the document object model becomes a reality), I suspect
this is going to be at least an eyesore if not a roadblock. Scripting is
creeping out beyond the browser, so a wide variety of documents are in for a
>Well, it would if the SGML CDATA element idea actually worked. But it
>doesn't, because the contents of a CDATA element are terminated by
>any <, or is it </, I forget at the moment, but anyhow, you can't,
>in practical terms, use CDATA elements for anything useful. If you
>could, they'd be in XML. (Tim)
What were they thinking? Too bad, because I do enjoy running my XML documents
through SGML parsers. It seems like XML's requirement for end tags should have
gotten us out of that mire, making a CDATA element run until it hits the
actual end tag, without any premature termination. Legacy standards...
>XML piggybacks everything on top of element structure. (Rick)
So did HTML, creating this problem. The HTML 3.2 DTD declares the SCRIPT
element as PCDATA, which I guess means the browser developers aren't playing
by real (SGML) parsing rules.
<!ELEMENT SCRIPT - - (#PCDATA)* -(%head.misc) -- script statements -->
>By the way, a quick look at Microsoft's ASP will reveal that they use
><% ... %> tags. How that is going to survive an XML parser, I have no
Can't say I ever liked <%...%>. Netscape's SERVER element always seemed like
a better idea, though it now has the same problems as SCRIPT.
>holes) is that -- as far as I can tell -- there's no way to put the
>code in a separate file from the HTML page. (David)
This is actually quite easy, and I do it all the time. <SCRIPT
isn't very difficult, fortunately. In practice, however, this is normally
used to bring in library files, which are then applied with code more specific
to the contents of the page. An abstract DOM that makes it easier to address
page content (and pages marked up more meaningfully) may make this a stronger
Back to the trenches.
Dynamic HTML: A Primer
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)