Using XML and Relational Databases for Internet Applications   Table of contents   Indexes   XML and Healthcare Vocabularies in Real-world Products
Cogitech Inc.
North Woodmere
Ogievetsky, Nikita
 USA 
 		Nikita Ogievetsky
 President
Cogitech Inc.
  646 Golf Drive North Woodmere  USA (11581)
Email: nogievet@offsight.com
 Biography
 Computer consultant since 1994. Specialize mainly in data-warehousing with SYBASE and SQL Server. Work with XML since 1997.
 Maintain http://www.cogx.com a web site devoted to XSLT and XML driven GUI.
 From 1981 to 1994 worked in the field of Neutrino astrophysics for Russian-German and American-Italian collaborations.
 Have over 15 publications on computer science, applied math and physics.
 

Introduction

 This presentation shows how XSL transformations can facilitate creation and management of interactive maintenance web sites. This is a second presentation of the series. First one took place at Metastructures 99 conference. There I used ASP to run dynamic server side JavaScript and MSXML processor as XSLT parser. This time we will use XT parser with Python wrapper to pre-process XSL transformations.
 We will generate a table maintenance web based front-end with object described in XML, screen designs and database API controlled by XSL, site map implemented as XLink. The provided mechanism can be easily extended to interactive maintenance of any object. This presentation shows a real-life corporate solution possible with the currently available set of tools.
 Using XSLT transformations we will generateinsert ,update , search ,search result and other action screens for table maintenance front-end. Database API and presentation templates will be separated into two independent stylesheets. Eventually we split creation of a web site into four separate layers:
 
  •  Object description (XML).
  •  Site map links (XLink).
  •  Database API (XSLT).
  •  Presentation and formatting (XSLT).
 

Setting task

 My team supports data warehouse production operation including adjustment system plus generates financial reports. We wanted a solution that would facilitate all of the following projects:
 
  •  Maintenance of lookup tables used for various Federal and Head-office reporting systems
  •  Maintenance of a proprietary general ledger system
  •  Maintenance of a proprietary job control utility
  •  Maintenance of risk management parameters such as risk weights
  •  Customer information maintenance
 Most of the assignments although formulated differently, are similar in essence. So we were challenged to provide an easy mechanism that would unload us and give users more power and let them manage lookup tables needed for reporting. These days advantages of providing new client tools with web based front-end are near to obvious. We want all table maintenance web sites look alike, so users will fill comfortable switching to a new site. Having all sites driven by a common server side mechanism will facilitate maintenance. Keeping all above in mind, XML driven approach comes in as the closest match.
 

XML object template

 The object in question will be described in a central XML document. XML though fairly simple has to obey a certain DTD. Additional business rules can be enforced through XML, such as mask or enumerated list of possible values used for data validation. Extended XLink element will describe site map for each maintenance web site. HTML, client and server side scripts will be serialized in XSLT templates.
 XSLT transformations applied to XML will build database API calls and presentation layers forinsert , update ,search , etc. action screens. Reusable XSLT stylesheets will be shared between table maintenance web sites. Change to one stylesheet will propagate to all action screens in all web sites that use this stylesheet. We can say that presentation and database API are encapsulated inside stylesheets. From the other side, change to XML document will propagate to all screens within one web site. Thus making routine changes becomes less elaborate.
 We will go even further: XSLT templates will be reused between stylesheets yielding to even higher level of OOP abstraction. Writing XSLT is straightforward and easy to debug. XML document will keep all parameters needed for runningupdate and select queries and displaying content on the web page. The particular implementation details such as database API and presentation formatting will be kept in common XSLT stylesheets.
 So development of a new web site is minimized to
 
  •  Describe a table in XML.
  •  Decide what action screens will be needed.
  •  Select XSLT templates for action screens out of pre-built stylesheet collection.
  •  Describe site map as extended XLink element.
 XML template for a fictitious General Ledger is shown in Picture 1.
 
 Picture 1. Sample XML template
 

Approach

 Creating new maintenance web site can be done with minimum efforts. This even can be entrusted to a business-side specialist. XML document can be automatically generated from a table object. A simple GUI can be provided to edit automatically generated business logic rules. The last think to do is to select which action screens are needed and connect them by XLink arks. Please Note that for general tasks a default XLink site map can be used.
 Once we have XML template we need a mechanism to fuel interactive web pages.
 We investigated 2 approaches:
 
  •  Using MSXML implementing 1998 XSL WD.
  •  Using XT implementing August 1999 XSLT WD.
 

MSXML and dynamic ASP scripts

 There is a single server-side ASP page with a JavaScript wrapper. As link is traversed, action role to activate is sent as one of the query string parameters. Server-side JavaScript wrapper interprets this parameter and:
 
  •  Changescurrent role attribute on the rootFORM element of the XML file.
  •  Retrieveslocator with xlink:id corresponding to the current role parameter.
  •  Changeshtml:title of the page according toxlink:title attribute of locator .
  •  Determines stylesheet to load fromxlink:href attribute and transforms XML.
  •  FromresultType attribute determines what to do with the result of transformation
  •  
    •  Sends result directly to the browser in the case of HTML
    •  Executes result viajavascript:eval() method in the case of JavaScript
 Block scheme of this approach is shown on Picture 2. This approach was presented at GCA Metastructures 99 conference in Montreal. Slides from this presentation are available at http://www.cogx.com/xwtl/presAll.asp.
 
 Picture 2. MSXML and ASP approach
 

XT and static server side scripts: House of bricks.

 A utility written in Python preprocesses XSLT transformations in batch and generates static HTML and ASP pages. No XSLT transformation is happening at the run time.
 Disadvantage : changes in XML file will be reflected in web pages only after batch transformations are re-processed.
 Advantage : faster execution because XSLT transformations are not happening on user request.
 XT implements August 1999 XSLT Working Draft. This means that we can modularize approach even further:
 
  •  Store named templates in a reusable template collection.
  •  Split presentation specific templates into presentation stylesheet andAPI specific layer into API stylesheet.
  •  Build main stylesheet for each screen from calls to presentation orAPI templates as from bricks.
 
 Picture 3. XT with Python wrapper approach
 
 Now each screen can be built out of 3-4 xsl:template-call elements. For example Search Entry Screen has
 
  •  All fields enabled and initiated with blanks.
  •  Hyperlinks / buttons to start the search or add a new record.
 Sea picture 4. Insert Entry screen also has all fields enabled, initiated with defaults values if any.
 
 Picture 4 Search Entry screen
 
 When search query is submitted, search results screen fetches all records that matches search criteria. When a record is selected for update, its unique identifier marked in XML template bypk attribute is sent to theUpdate Entry screen. Update Entry screen:
 
  •  Finds the record by its primary key (fields with pk attribute set to true)
  •  Displays current values for all fields in the entry form, leaving pk fields disabled.
  •  From this screen user can either go back toSearch Entry orCommit Update .
     See picture 5.
 
 Picture 5 Update Entry Screen
 When user decides to commit update, server side script:
 
  •  Validates entry fields against business logic expressed by mask attributes
  •  Executes update query
  •  Selects updated record
  •  For confirmation purposes displays updated record in the form with all fields disabled.
 Sea picture 6.
 
 Picture 6. Execute Update Confirmation
 
 On pictures 4,5,6FORM template has two parameters :
 enabled with possible values:
 
  •  true - all fields are enabled and editable
  •  false - all fields are disabled
  •  non-pk - all but pk fields are enabled and editable; pk fields are disabled.
 value-set with possible values:
 
  •  blank - fields are initiated with blanks
  •  default - fields are initiated with defaults
  •  query - fields are initiated with the values of the current table record
 Using proprietaryxt:document extension we can combine stylesheets for all screens in one stylesheet-city. XLink in this scenario is transformed into a collection of static web pages with hyperlinks (or buttons playing roles of hyperlinks). As XT reads site map, it generates screens only for roles designated to this web site. This is determined by xlink:locator elements. Links are generated according to xlink:arc elements. Extending our metaphor, extended link is a map used to build web site-city from screens-houses constructed from xsl:template-bricks and connected by xlink:arc-streets. Sea picture 7. It corresponds to XML template shown on Picture 1.
 
 Picture 7. Xity map
 
 Picture 8 shows template generating links as buttons.
 
 Picture 8. Links as buttons
 Picture 9 shows template-wrapper that adds all the necessary HTML tags and writes HTML or ASP page. In the case of ASP it adds common server-side JavaScript functions.
 
 Picture 9. Template that actually writes files
 
 

XSLT Constructor game

 To demonstrate merits of our approach let us build a new screen from existing blocks. Some times, especially in the case of de-normalized data structure, one have to add a new record with most of the fields equal to fields of an existing one. In this case a cloning mechanism makes sense. User can clone a record selected on a search screen, or clone just inserted or updated record. Clone screen:
 
  •  Finds original record by its primary key (fields with pk attribute set to true)
  •  Displays current values for all fields in the clone entry form, all fields includingpk are enabled and editable.
  •  From clone screen user can either go back toSearch Entry orCommit Insert .
 Clone screen is similar to edit screen. Differences: in edit screen pk fields are disabled, in clone screen all fields are enabled, edited record is inserted, not updated. To add this new screen to a web we have to add one locator and five arcs to the xity map. See picture 10:
 
 Picture 10. Clone Addition to the xity map. Arcs-Streets.
 Picture 11 shows the main blocks used to build new clone screen. Compare it to blocks used for edit (update entry) screen in picture 5:
 
 Picture 11. Clone screen built from blocks.
 Picture 12 shows xity map after the new clone screen is added:
 
 Picture 12. Clone Entry building added to the Xity
 

Sample templates

 Links template was shown on picture 8. Entry/Display Form template from presentation layer is shown in picture 13.
 
 Picture 13. E/D Form template.
 Form template usesrs-value and rs-selected templates defined in API layer. They can be replaced if a different database API is used. In other words for template library to work, API stylesheet should exposers-value andrs-selected templates. So we are back to defining interfaces. Picture 14 showsrs-value and rs-selected templates for ASP and ADO.
 
 Picture 14. rs-value and rs-selected templates.
 Update is another template that API stylesheet should expose in its interface. It creates and executes update statement.Update template used in our case is shown on picture 15.
 
 Picture 15. update template.
 <SS> tag should be replaced withserver side script tag. Update template uses internal templates "methods":
 _where-pk builds where clause by pk fields,
 _qfvalue writes a form string value surrounded by quotes in case of character fields.
 _last-coma puts a coma separator everywhere but after the last node.
 This templates along with subsequently referred _fvalue and _last-and templates are shown in picture 16.
 
 Picture 16. some internal templates of API stylesheet.
 At last Python wrapper is shown in picture 17. It starts XT XSLT processor which outputs web pages with html method (see picture 9). There is some clean-up needs to be done to make valid ASP pages:
 
  •  add JavaScript language declaration before HTML document type declaration,
  •  add ASP include statements,
  •  de-escape special characters.
 
 Picture 17. Python wrapper script.
 You can find other details and source code at http://www.cogx.com You are welcome to make your own developments and add new bricks and blocks to Xity constructor. Add your URL or post your examples at http://www.cogx.com/xwtl/links.asp
 

Conclusions

 UsingXSLT web template library with Xity constructor allows separation of development process into four layers:
 
  •  Data structure and business rules in XML object description. In most cases it will be the only document needed to create a new web site.
  •  Site map implemented as extended XLink. Facilitated site map maintenance. Add/remove/modify XLink arcs and locators to administrate site map.
  •  Database API serialized in XSLT templates in API stylesheet. Has to expose certain templates (methods), i.e. conform to a certain interface.
  •  Presentation and formatting serialized in Presentation stylesheet.
 High level of modularization allows developers to change only one of the layers living others as untouched.
 Object (table) structure is described in XML so there is no need to hardcode table field properties in server side scripts or retrieve them dynamically in run-time from the database, thus simplifying code maintenance and reducing number of database calls.
 XML based and hence easy integration with other systems and extensible.
 Client requirements: any HTML4 aware browser. Simplified user training and client installation.
 

References

 
  •  XSL Transformations (XSLT) Working Draft 9 July 1999 http://www.w3.org/1999/07/WD-xslt-19990709
  •  XML Path Language (XPath) Working Draft 9 July 1999 http://www.w3.org/1999/07/WD-xpath-19990709
  •  W3C XML Linking Language Working Draft http://www.w3.org/1999/07/WD-xlink-19990726
  •  XML XLink Requirements http://www.w3.org/TR/1999/NOTE-xlink-req-19990224
  •  XML Linking Language (XLink) Design Principles http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303
  •  The SGML/XML Web Page by Robin Cover http://www.oasis-open.org/cover/
  •  XSL-List Archive http://www.mulberrytech.com/xsl/xsl-list/archive/
  •  XML-DEV Archive http://www.lists.ic.ac.uk/hypermail/xml-dev/
  •  St. Laurent Open-source XLink library http://www.simonstl.com/projects/xlinkfilter/index.html
  •  XT Version 19990822 http://www.jclark.com/xml/xt.html
  •  Python Language Website http://www.python.org
  •  XML at Microsoft http://msdn.microsoft.com/xml/c-frame.htm#/xml/default.asp
  •  HTML Forms with XSLT @ Metastructures 99 http://www.cogx.com/xwtl/presAll.asp
Using XML and Relational Databases for Internet Applications   Table of contents   Indexes   XML and Healthcare Vocabularies in Real-world Products