Re: Proposal to unify Fill-in, Insert and Data/Presentation Independence

sdo@novell.com wrote:
>If you recall, there was a thread a few weeks ago about filling in
>certain form fields with pre-specified information (e.g., your
>Email field would get initialized in any Form), and of course,
>there's the INSERT conversation going on now.  I will address these
>later.
>
>I wanted to present this here first, with the possibility that I would
>follow up with an Internet Draft.  Please forgive the length of
>this posting.  I just switched companies, and I don't have a
>convenient ftp/web site to put this on.
>
>[... proposals for standarized Client-Side Includes (CSIs) ...]

	Bearing in mind that the INSERT draft is in the process of
being revised, it already enables insertion of static or dynamic
HTML fragments, with no need to modify servers if that's what's
providing the fragments, and only minor mods needed for the client
software.  You can insert static fragments via:

<INSERT
   type="text/chtml"
   data="http:/host[:port/path/foo.chtml">
Altenative markup, or zilch, for INSERT-blind clients.
</INSERT>

where .chtml has been mapped to text/chtml in your server's configuration
file.

	For dynamic inserts, you can use:

<INSERT
   type="text/chtml"
   data="http:/host[:port/script_path[/path_info][?pseudo_query]">
Altenative markup, or zilch, for INSERT-blind clients.
</INSERT>

for invoking a CGI script, with PATH_INFO and QUERY_STRING
environment variables for instructing the script on what
fragment to create.

	You also can use other standard types, not necessarily a
"made up" one for CSIs, but point via data= to a script which
handles what's returned dynamically.  For "text/chtml", the
client needs some minor initialization and configuration tweaks
for recognizing and handling that as an HTML fragment insert (and
confidence that the fragment won't create bad HTML within the
surrounding markup).  Most importantly, the client also needs tweaks
not to include the fragment in any file cache it creates for the
overall document, and that's simple to "engineer" for a distinct
type (e.g., "text/chtml"), but some clear attribute to indicate
that for standard types is needed.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Thursday, 21 March 1996 10:29:03 UTC