- From: <sdo@novell.com>
- Date: Thu, 21 Mar 1996 09:30 EST
- To: www-html@w3.org
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 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. 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 service. 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 PRICE=100 A more useful service could take a list of symbols, and return a corresponding list of quotes: SYMBOL=MSFT SYMBOL=NSCP SYMBOL=IBM and return: Content-type: application/x-www-form-urlencoded PRICE=100 PRICE=200 PRICE=300 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 be: <<TYPE=type NAME=name FMT=format DEFAULT=default BIND=binding>> where type = IFIELD | OFIELD | CMD | ENV | FILE | URL | SVAR | BVAR where: 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 printed). 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> <INPUT TYPE=HIDDEN NAME="SRVCNM" VALUE="INQUIRY"> <BR> <INPUT TYPE="submit" VALUE="INQUIRY"> </FORM> (I left out the HEAD and BODY stuff). The output template is: <title>Bankapp Results Screen</title> </head> <body> <H2>Transaction INQUIRY Succeeded on <<TYPE=CMD NAME=date>></H2> <br> <H3> Account <<TYPE=IFIELD NAME=ACCOUNT_ID>> <<TYPE=OFIELD NAME=SBALANCE FMT="BALANCE=%s">> </H3> <HR> <H2>Note to customers:</H2> <<TYPE=FILE NAME=notice-of-the-day DEFAULT="No notices">> <HR> 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 <TABLE> <TR><TH>Symbol</TH><TH>Price</TH></TR> <<TYPE=IFIELD NAME=SYMBOL[0] FMT="<TR><TD>%s</TD>">> <<TYPE=OFIELD NAME=QUOTE[0] FMT="<TD>%s</TD></TR>">> <<TYPE=IFIELD NAME=SYMBOL[1] FMT="<TR><TD>%s</TD>">> <<TYPE=OFIELD NAME=QUOTE[1] FMT="<TD>%s</TD></TR>">> <<TYPE=IFIELD NAME=SYMBOL[2] FMT="<TR><TD>%s</TD>">> <<TYPE=OFIELD NAME=QUOTE[2] FMT="<TD>%s</TD></TR>">> <<TYPE=IFIELD NAME=SYMBOL[3] FMT="<TR><TD>%s</TD>">> <<TYPE=OFIELD NAME=QUOTE[3] FMT="<TD>%s</TD></TR>">> . . . </TABLE> 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: <FORM ACTION=... > Email address <INPUT SIZE=20 NAME=EMAIL <<TYPE=BVAR NAME=user_email FMT="VALUE=\"%s\"">> > </FORM> 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: <P> The next paragraph will be in a style defined by the user. <P> <<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: <P> 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 sdo@novell.com (or orshan@acm.org 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). http://www.beasys.com (doesn't quite work yet) http://www.inter.net/beasys http://tuxedo.novell.com
Received on Thursday, 21 March 1996 09:39:01 UTC