Odd is on way to describe it, I would say "frustrating".
>> Since HTML <= 4.0 is *not* XML, it is best to treat it as an output
>> format, like PDF, TeX, RDF, Postscript, etc. -- in other words, first
>> produce your XML, then run it through a filter (such as a SAX-based
>> app) that does a down-translation to HTML syntax.
This doesn't have to be a very complicated animal. If I wanted to, I
could generate something that is ~almost~ HTML by doing things like <BR/>
and <IMG .../>. From there, a one line regular expression would make my
pages be readable by the major browsers. (Interesting aside, IE will
display the right thing if you close a stand-along tag with />, but
Netscape will not)
It sounds like the smart thing to do is write an XML to HTML converter as
you suggest.
The scripting workaround isn't as hard as it seems. You're example of...
document.write("She said "run"")
...would actually get turned into...
document.write("She said &quot;run&quot;")
So, if we just go through and replace all the predefined entities with
the literal characters they represent, the workaround works.
The fact that including a script in the generated file requires a
seperate utility will, I expect, become a non-trivial barrier to the
broader acceptance of XSL. I hope the working group chooses to address this
in their second draft.
<stating-the-obvious>Java Script engines are not easy things to
write.</stating-the-obvious> I think it's unlikely that developers are
going to redefine the Java Script language to interpret < as < ... my
opinion (hope) is that the standard should accomodate this.
-- Andrew
Andrew Bunner
President, Founder Mass Quantities, Inc.
Professional Supplements for the Perfect Physique
http://www.massquantities.com