Reply-to: gcf@npac.syr.edu To: walczak@boss, marek@boss Subject: XML Date: Mon, 01 Jun 1998 21:32:13 -0400 From: Geoffrey Fox So I spent a bit of time studying XML and I believe there is no doubt that we should use XML SYNTAX to replace {} syntax. How XML effects logic of current templates is less clear to me. Here are some remarks with varying degree of detail and certainty. 1) First I note that XML appears very important to Tango in general, as it is natural interchange language for data. Namely it is much better than HTML as the export language for systems like Lotus Notes, databases, GIS systems etc. Thus I expect, as Tango applications multiply, more and more will be built around XML with at some time a shared XML browser being the basic collaborative tool. 2) I see some competition between CORBA IDL and server side XML. 3) The documents I read implicitly assumed largely client side processing of XML but I that server side processing of XML (to either HTML or XML again if as in our application one is only processing some specified XML tags) is very reasonable. If as in our case, XML tags access database entries, the server side is most efficient. 4) As a first suggestion, something like {title} would become and {protectedtitle} where fetches information from the WebWisdom education object database. The filter "protect" is available for all character strings and escapes ' and ". 5) One could also have for formatting information. 6) I don't know if you have studied wwwalias yet but this is a database (a text file in lousy old wwwfoil.pl implementation) of URL's labeled with short alias. This would be set up as a new table in WebWisdom NT and would generate the link Y where url URL is associated with alias X in the database. According to wwwalias rules, if title=Y is absent, one uses default title TITLE contained in WebWisdom NT database for this alias entry. Thus link generated is then TITLE. Thus current syntax {X}() becomes and Syntax {X}(Y) becomes 7) Finally note that some of {constructs} such as {help} are in fact translated to "simple XML" as these constructs defined in file perswww are just short cuts to HTML -- something which XML enables without any special processing. We should however process things like in Webwisdom NT servlet so that we are not dependent on an XML browser. 8) Thus I propose that servlet translate XML compatible template to XML (with fewer tags) browser files with a configuration file that tells servlet which tags it is to process. Initially final"XML" is in fact HTML. This servlet "configuration" file can of course just be a XML compliant webwisdom.dtd file containing format DTD for tags servlet recognizes. I believe this strategy would allow extensibility quite nicely. I think this will work although note servlet must as in any HTML parser, be able to recursively process nested tags. 9) Note XML allows one to use text files to cleanly specify database records e.g. wwwalias comma separated file would become a set of entries like This type of syntax strategy, would allow us to choose either database or text file storage for the various tables in WebWisdom NT. This could be valuable when we wish to operate without a database. 10) Reviewing XML, I see WebWisdom uses some deprecated tags. We should probably move away from these e.g. is deprecated Now we come to some less clear areas 11) There is a still evolving set of tags, which have logic capability. Further they can invoke ECMAScript which is meant to be (Microsoft initiated) industry standard JavaScript. It is not clear here if JavaScript becomes "Livewire" if used server side as we envisage here. So we can take care of "arithmetic" in current templates in several ways. 12) The simplest approach is illustrated below for a {select} (i.e. conditional) statement, which could change from {select=123} to something like STUFF where STUFF is returned if imagestyle 1 2 or 3 but otherwise nothing is returned. Note statements must be nested in general. We can process WWIF fully in Java servlet or map into some equivalent XSL or ECMAScript form. The servlet processing is not as general but easiest to implement. 13) An advantage of using XSL or ECMAScript is that one could more easily define natural arithmetic (max, +-1) etc on database entries. In Java version, even simple arithmetic has to be mapped into a special filter. The latter is how I do it in current Perl Program. 14) I note an interesting tag . I believe this might be usable to generate the loops that needed in templates.