Proposal to unify Fill-in, Insert and Data/Presentation Independence
Thu, 21 Mar 1996 09:30 EST

Date: Thu, 21 Mar 1996 09:30 EST
Subject: Proposal to unify Fill-in, Insert and Data/Presentation Independence
Message-Id: <>

Hello HTML List,

I have been following this list for a couple of months,
and I have been working with Web technology for a couple of years,
and I believe that my work is relevant to several discussions that
have gone on here.

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

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.

Please copy me on any followups.  I receive the list
as a digest, and sometimes it takes a day or more for enough to
accumulate to produce a new digest.

I wasn't sure if this was more appropriate to www-html or www-talk,
but it fits in with discussions that have happened in www-html, and
I didn't think it was appropriate to cross-post to the two lists.
I'm sure I'd get flamed wherever I put it.

1. Introduction

For the past couple of months, I have been trying to define a way
to interface Web browsers to a traditional client/server system
(interesting how client/server is now traditional).

A very valuable characteristic of properly architected client-server
systems is that the business "services" accept and return data, and do not
specify how the data are presented to the caller.  In fact, the
services need not know whether the caller is a user, or another

Then the Web came along, with CGI as its service model, and broke
this Data/Presentation independence.  A Web "service," be it a CGI
program or a server plugin, returns presentable HTML to the
browser.  The application logic has to also format the output.

This not only creates more network traffic than necessary, but it
does not allow the user to choose the presentation format, if any,
for what may be a tiny piece of data.

[As you are reading what follows, you will be saying to yourselves, "This is
INSERT," or "This is server-side includes," or "This is
stylesheets."  If one of those facilities can be better used, then
great - I simply chose what is defined below as an easily
implementable, not-to-be-confused-with-any-existing-tag model for
the functionality I an trying to achieve.  I've also read some mention
of using the C preprocessor or m4 to achieve some variability in an
HTML document, but this does not meet my needs.]

2. Example

Time for an example.  There are a number of stock quote services on
the Web.  Each looks different.  In order to send me back a stock
quote, the service has to send me all of the surrounding HTML.  Why
should it do this when I already have the HTML from the last
request?  Or maybe I want to display the quote in the middle of
some other text, or in a table.  Maybe I want one CGI program to
call the services of another completely different Web server.

I want to display my complete financial picture.  To do this, I want
to display my bank account balances, and the prices of some stocks
I own, all on one Web page.

3. Return x-www-form-urlencoded Data

When I POST a request to a web service, I send it data in the
x-www-form-urlencoded format.  Let's say that the input
to the stock quote service is SYMBOL=W3STOCK.  Why shouldn't the
service just return PRICE=100, or more specifically:

	Content-type: application/x-www-form-urlencoded


A more useful service could take a list of symbols, and return a
corresponding list of quotes:


and return:

	Content-type: application/x-www-form-urlencoded


If Web services could return data (or choose whether to return data or
HTML, depending on the HTTP_ACCEPT variable), then I could write
composite Web services that combined the output of other Web services.

This is the essence of what is called "transparency," and is what our
product and products like it have been enabling for many years.

4. Make it into HTML

In order to turn the result into HTML, I have defined an HTML template
language.  (It's not really HTML specific, but let's call it that for now.)
What you will see below is NOT html.  No browser will be asked to
display this, and it does not have a DTD.  My hope is that browsers
or web servers will, in fact, implement this, but it is a new MIME type
or Content-encoding, not text/html.  (I was thinking text/phtml -
Preprocessed HTML, or Primordial HTML.)

Somewhere, someone specifies which template is used.  Im my
implementation, where I do the expansion in a CGI program, I allow
for three possibilities: an input field named OUTFORM, with the
value being the name of the file containing the template; an output
field from the application code (although the application shouldn't
have to know its output is being shown via one of these templates);
or a default, which is the name of the "service," or derived from
the name of the service, as in some sort of repository.  I have an
intermediate layer that adds the OUTFORM, so that the application
layer can remain pure.

This is an inverted INSERT or SSI; the document does not include the
data -- The data asks to be included in a document.

5. The Language

Anywhere inside the template (maybe not inside quoted strings), can

	<<TYPE=type NAME=name FMT=format DEFAULT=default BIND=binding>>


		IFIELD=A POST or GET Input field (from the browser)
		OFIELD=An output field from the application service
		CMD=A command
		ENV=An environment variable
		FILE=The contents of the file
		URL=The output of retrieving the URL
		SVAR=A server specific variable
		BVAR=A browser specific variable
	name = fieldname[index] | command-string | file | environment-var | URL
	FMT = a printf string with no more than one %s in it (default is %s).
	DEFAULT = what to substitute if the field, file, etc. is
		not available.  (Without a default, nothing is
	BIND = I haven't really defined this yet, but it indicates a
		preference for who is responsible for replacing this
		template item.
		Possible values are "browser" or "server" or "printer".

	The attributes can be in any order within the "tag".

6. Another example

In the product I work on, there are named services, and they take a
buffer type called FML that is isomorphic to an HTTP query (i.e., field=value
pairs).  To specify these services, the input HTML FORM also has an
input field called SRVCNM.

One of our sample services is a banking application.  There is a
service name called INQUIRY, which takes a field called ACCOUNT_ID
as input and outputs a field called SBALANCE.

	Input			Output
	ACCOUNT_ID=12345678	SBALANCE=$2500.00

[Yes, I know - SBALANCE should be a raw number, but this is what I'm
working with now.]

The input HTML is:

<TITLE>Bankapp Balance INQUIRY</TITLE>
<H1>Bankapp Balance INQUIRY</H1>

<FORM ACTION="http:/cgi-bin/tuxsvc" METHOD="POST">
<B>Account Number </B> <INPUT SIZE=6 NAME="ACCOUNT_ID"><P>

(I left out the HEAD and BODY stuff).

The output template is:

<title>Bankapp Results Screen</title>
<H2>Transaction INQUIRY Succeeded on <<TYPE=CMD NAME=date>></H2>
<H2>Note to customers:</H2>
<<TYPE=FILE NAME=notice-of-the-day DEFAULT="No notices">>

Now, if the browser were to implement this, each user could have his or her
own template, and make the output fields appear in any format whatsoever.

Or this service could be called by another, which wouldn't have to
strip out all of the nasty html that comes out of CGI programs.

7. More powerful examples

Because I have said that the default behavior of the << >> "tags" is to
output nothing when the input parameter is not found, the following
powerful constructs are possible:

#stock quote example






This produces just as many table rows as there are stock symbols in the input.


Here's an example for those wanting automatic-form-fill-in:

Email address
<INPUT SIZE=20 NAME=EMAIL <<TYPE=BVAR NAME=user_email FMT="VALUE=\"%s\"">> >

where there is some predefined set of browser variables that can be
retrieved.  Since that's not happening soon, a TYPE=ENV could be
substituted, and the appropriate values could be kept in the environment.

Or, when a user signed up with a service, the initial form could return
a mini-database text file with the user's preferences for that service.

A TYPE=CMD replacement could be done to sed, awk, or perl the desired
information (I know - big security hole).


Another example - style-setting for stylesheet-challenged browsers:

The next paragraph will be in a style defined by the user.
<<TYPE=FILE NAME="style3.begin" DEFAULT="<H3>">>
I don't know how this will look, but the style3.begin file has the
proper markup.
<<TYPE=FILE NAME="style3.end" DEFAULT="</H3>">>


Because this language is not HTML, it can even appear inside HTML tags:

Set the next header level.
<H<<TYPE=CMD NAME="echo -n 3">>>This is in H3 format</H<<TYPE=ENV NAME=THREE>>>

8. Further Extensions

- The TYPE should really be a URL Protocol value, e.g., "env:PATH".
  Then it would map better to INSERT.
- Data Values are always strings now. Perhaps a type indicator should be added.
- There are no looping constructs on purpose.  Once looping and conditionals
  are needed, then one of the scripting languages should be used.
- Despite that, some minor conditional processing could be added, for
  example, to select the output template based on a boolean test of
  various variables. E.g.:

  (QUOTE > 100?OUTFORM=sell:OUTFORM=buy) or
  (REMOTE_HOST~/.*fr/ ? OUTFORM=frenchform:OUTFORM=englishform)

- I could be convinced to add some more creeping-language-isms, but not many.

9. Further Discussion

Other than flaming me for the length of this proposal, I'd like to open it up
for comment.  Whatever you propose, remember the primary point of this for me:
I need to have application logic that simply returns data/value pairs,
and somehow convert it to HTML, either in a CGI program, a Web-server
plugin, natively in the Web server, in a browser plug-in or natively in the
browser.  I would prefer that the templates could be cached near the
browser, and different users could use different templates.

I know that there are proprietary languages for doing database retrieval,
and displaying those data values as HTML, but I'm operating at
the business-logic level, not the data retrieval level.

	Thanks (and please don't include this whole posting in your replies),

	Scott Orshan
	BEA Systems, Inc. (Formerly Novell)
	TUXEDO Engineering Group/TPC Representative
	+1-201-443-5063 (or if the Novell address stops working)

	TUXEDO is the leading open distributed transaction processing
	software.  BEA Systems has taken over development of TUXEDO
	from Novell (who got it from USL, who got it from AT&T). (doesn't quite work yet)