Re: Proposal to unify Fill-in, Insert and Data/Presentation Independence
Thu, 21 Mar 1996 16:50 EST

To: (Foteos Macrides)
Date: Thu, 21 Mar 1996 16:50 EST
Subject: Re: Proposal to unify Fill-in, Insert and Data/Presentation Independence
Message-Id: <>

 >Date: Thu, 21 Mar 1996 10:29:20 -0500 (EST)
 >From: MACRIDES@SCI.WFBR.EDU  (Foteos Macrides)
 >Message-ID: <01I2LICAGGW2007392@SCI.WFBR.EDU>
 >	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:
 >   type="text/chtml"
 >   data="http:/host[:port/path/foo.chtml">
 >Altenative markup, or zilch, for INSERT-blind clients.
 >where .chtml has been mapped to text/chtml in your server's configuration
 >	For dynamic inserts, you can use:
 >   type="text/chtml"
 >   data="http:/host[:port/script_path[/path_info][?pseudo_query]">
 >Altenative markup, or zilch, for INSERT-blind clients.
 >for invoking a CGI script, with PATH_INFO and QUERY_STRING
 >environment variables for instructing the script on what
 >fragment to create.

Unfortunately, I am trying to define the substitution language for the
output of a CGI program that has already been called by another FORM
or even INSERT tag, as you have described above.

I would like to input a request on a FORM, which submits a POST or GET
query to a Web "service."  Although I have not said that the service
protocol must be CGI, I have said that the data format is convenient for
many data transfer applications (FIELD=VALUE pairs).

I don't necessarily want the output to appear on the input form.

I also do not want to be tied to HTML.  There's no reason why my language
couldn't be used as a pre-gif or pre-txt, rather than just pre-html.

To refine my proposal a bit, let's assume the native Content-Type,
but a Content-Encoding of "field-substitute".  However, I doubt
whether the content encoding can be passed into the HTTP_ACCEPT header,
such that a script or server could decide whether or not to expand the
output itself.

 >	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.

My goal is to only send back the stuff to be included (the includ-ee)
rather than the document that will later include some other stuff
(the includ-er).  Some external mapping specifies (perhaps based on data
or service name content) the includ-er document, in which some, all, or none
of the includ-ee fields are substituted.

It's an include-me protocol, rather than an include-this protocol.

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

	Scott Orshan
	BEA Systems (Formerly Novell) TUXEDO Engineering Group