If you've ever tried to write a CGI program, in, say C/C++, you promptly run into the problem having potentially significant amounts of html text buried in your C/C++ code. This is bad, for a number of reasons:
Doing so risks getting your code corrupted by somone who doesn't know C, and/or modifications to your C code you would not approve of (subtle bugs, malicious changes, etc.)
There is a simple way of solving this problem -- it can be done by introducing a simple extension to HTML. Why, you may ask, is an extension needed? Because you want WYSIWYG HTML editors to be able to handle this stuff automatically.
I've developed a mini-extension to html to handle this. I am writing this note to ask if anyone else has done anything similar, if there have been any previous discussions of this sort, if anyone has code, etc.
Technically, this extension is no longer html, since (at this time) you would not want to send this to an html viewer (you may in the future; could be useful for MUD's MOO's VRML, etc. -- but not now). The idea is for an "anti-form" or "template" that a filter program would parse, generating final, real HTML. The syntax is reminiscent forms, except that the forms or "templates" are filled out automatically by the filter program, rather than a human.
So, for example, consider the following example of "HTTL" (hypertext template language):
<b> The time is now <template name="time">. Do you know where your parents are? </b>The HTTL-to-HTML filter program parses this, recognizes the keyword "time" and substitues for it, generating the following valid html:
<b> The time is now 9:52. Dou you know where your parents are? </b>How the filter handles keywords is entirely up to the person writing the filter. There are no predefined keywords.
In short, that's it, that's the idea. I have some further ideas on this, but let me keep this breif. (e.g. you may want to specify a "context" or "database" that indicates to the filter where to look for keys or how to treat them. Another intersting application is having the key's be URL's -- this becomes a mechanism for in-lining html. And keyes that themselves specify other cgi programs that generate in-lined html .. hmmm. In the distant future, you may want viewers to support HTTL, as this could help with caching, be a mechanism for transmitting/broadcasting minimal update info in the same way that DIS (a 3D defense industry battlefield simulaion protocol) is used by the military broadcast minimal updates. But that's for later.)
Please reply directly to linas@fc.net. I do not subscribe to some of these mailing lists, although I can be pressured into doing so.