- From: <lee@sq.com>
- Date: Thu, 30 Jan 97 22:02:05 EST
- To: w3c-sgml-wg@www10.w3.org
> It wasn't meant to be a fair question? It is an honest one and > it elicited the honest response: fatten the file with more > markup and syntactic stuff needed to isolate the inline scripting, > and hey, it's XML. I'm sorry that I wasn't clear in what I meant by unfair. The example Len had is fairly common: intermingled HTML and program code. What happens is that the file resides in this form on a server and is never actually served up like that. It won't open in some HTML editors either, and other HTML editors will mess it up completely. It won't parse according to any SGML DTD. That's OK. It's sort of like saving a 16-track recording of a band without the vocals and lead guitar, and adding those later. It doesn't matter too much what it sounds like if you play it without the vocals and lead guitar to most people, as long as it's in tune and keeps time -- what matters is the final mix. In the same way, this proto-HTML document is processed by the LiveWire web server when it is requested, and the final tracks are mixed in -- replacing everything between <SERVER> and </SERVER> with the result of running that code. So the XML client never sees <SERVER>, and never sees the code. So it doesn't matter thta it'snot valid XML. Now, if Netscape wanted to make a LiveWire development environment that was XML-based, they'd have to use <P> instead of <P> in the example, or use CDATA marked sections. It wouldn't matter if it was all hidden behind icons anyway. But since these things are actually edited by programmers (they have to be, because of the code), it's normally going to be a programmer's editor that's used, not an off-the-shelf HTML or XML editor, and it is not an issue. To test this sort of document, you have to serve it up and validate the result. And _that_ had better be in tune, in time, and proper XML! Lee
Received on Thursday, 30 January 1997 22:45:03 UTC