Re: Inline code a mistake?

Paul Prescod wrote:
> 
> As I understand it, the main argument for embedding inline code is
> convenience and performance.
> 
> Convenience:
> 
> I think that the important thing to remember is that a URL represents a web
> "object", not a file. You can _encode_ a URL as multiple files (i.e. server
> side includes). Or you can use one file to create many URL(i.e. inline CGI).
> 
> Inline script code can be converted by the server into a _reference_ to
> another URL (where the server stores the script file). That way the author
> gets the convenience of "inline coding" and the Web maintains the separation
> of code from document content (which results in simpler, smaller, cheaper,
> faster, more stable client software).
> 
> Anyhow, I tend to think that editing problems should be solved in editing
> software, not in the interchange language.
> 
> Performance:
> 
> On a high-bandwidth line, bringing down scripts and text separately might be
> faster because it can be done concurrently. On a low-bandwidth line, HTTP
> persistent connections should make the performance difference between inline
> and out-of-line quite small.
> 
>  Paul Prescod

Inline code is part of the more important concept of allowing 
true context-sensitive lexing in HTML.  For each section of any 
compound document, the parser should rely on section headers or 
DTD's before continuing the parse.  Only in this way can HTML 
grow and become an all-encompassing document specification... 
allowing people to define new languages and new uses for the Web 
- while maintaining document integrity.

I know HTML is *not* a compound document specificaion, but 
compound documents have the distinct advantage of NOT being a 
part of an OS-dependent "slash-delimited directory-tree" 
concept.

The simplest definition of a new parsing context would be:
<SOMETAG NAME=SOMENAME MIME=my/mime DELIMITER="----!!!arbitrary 
delimiter!!!----">
</SOMETAG>

This would take advantage of the MIME specs, and allow for 
embedded scripts, IMAGE HREF's to embedded images, embedded JAVA 
byte code, etc --- all within a easily parsable document.

...OR we could write a bunch of YACC-like stuff and put it in 
the header of each section (not).


<!------some additional babble-------!>

...it's not THAT hard to read a delimiter, open a file, write to 
it until the delimiter is found, and then use the file as if it 
were located on the host machine

...it IS hard to read an embedded DTD, reconfigure the parser 
and rethink the next section of the document.

<!--------------------------
      ...elipses boy
--------------------------!>

Received on Monday, 6 May 1996 11:28:12 UTC