EXECUTIVE SUMMARY
This case study covers the development of a web based application using XML.This application is intended to be used by a telephonist taking orders for a bookstore.
XML offers Interoperability across software systems.
An outline of the system is explained in detail, which goes on to include the following:
- Data Input
- Validation
- Data Viewer
- General – Links to all pages
A Closer look at XML
Charles F. Goldfarb is the father of what we know today as XML (Extensible Mark-up Language). He also invented SGML, the Standard Generalised Mark-up Language which is the foundation to both XML and HTML.
XML began as a tool for publishers to describe the contents of documents exchanged over the Internet, but it soon became popular as a method for describing any form of data. For example, the language provides terms used to define a Web document’s tags which are the elements of the document that further describe its various attributes and the relationships between them. Developers at either end of a data exchange then agree to use a common set of tags.
XML is widely used between business to business transactions. XML acts as a universal language. “Interoperability between ontologies is a big, if not the single biggest issue in B2B data exchange. For the foreseeable future”, Marc de Graauw August 21, 2002.
DATA INPUT – Outline of the System
Product Quantities
The Author’s Web Based Order form has been designed to allow the telephonist to enter up to 5 products with ISBN codes and 5 products with the EAN 13 codes.
Products Price and Product Description Details
Every product is priced at £100. This means that if 4 products are entered the total is £400 and 10 products would total £1000 respectively. This of course excludes the delivery costs.
Justification for Products Price and Product Description Details Method
Since the Web Based Order Form “will form part of a larger system” (Ref. Assessment Details) the Author is of the opinion that realistically the telephonist shall not be required to enter the product price or any product description information such as, it’s name or description.
The Author is of the assumption that due to the fact that “Products being ordered will be identified and entered into the system by the following: Product code (EAN 13)” and “ISBN” codes; logically speaking these codes are the only details of a product which need to be entered into the Web Based Order Form by the telephonist. The Author has further made the assumption that the Web Based Order Form that is to “form part of a larger system” (Ref. Assessment Details) indicates that the larger system may involve a database that would contain a table of perhaps all the product information and utilise the EAN 13 and or the ISBN codes as the primary key field.
Figure 1 below illustrates the Author’s assumption.
Figure 1 Overview of the System
Examining Figure 1 Overview of the System
Stage 1 – Data Input
Product, customer, payment and delivery details are collected.
Stage 2 – Validation
All details are validated with regular expressions and other server-side validation processes. Until all the entered information is valid the web application will not progress to Stage 3. The telephonist will be prompted to correct his/her errors before trying to save the order as an XML file.
Stage 3 – XML Creation
The order is saved as an XML file. Stages 1 to 3 represent the scope of the Author’s Web Application. Stage 4 is the anticipated “larger system”.
Stage 4 – Larger System Interaction Using XML
The XML file only contains either the ISBN or the EAN 13 codes of a product for the purposes of identifying a product. The XML file can be opened into an ASP page with the TextStream Object and either the ISBN or EAN 13 code stored in a variable. The variable containing the Product_ID can be passed to an SQL statement which retrieves all or however many product record fields required.
The example SQL shows how this can be done:
SELECT * FROM Products WHERE Product_ID = ‘” & strProductCode & “‘”
Please note the strProductCode variable contains the ISBN product for Charles F. Goldfarb’s XML Handbook which is 0-13-065198-2. The result of the SQL statement shall retrieve all the information of the product illustrated in Stage 4 of Figure 1.
Conclusion
As mentioned earlier, realistically the telephonist shall not be required to enter any information about a product other than the ISBN or the EAN 13 codes as this would suggest that the telephonist must know all the information about all the products. Surely if a customer was ordering many products it would take longer for the telephonist to type in the orders into the Web Application, where as only entering the ISBN and or EAN13 codes would trigger a database and thus retrieve the product details. This would prove far more effective as it minimises the chance of error whilst typing and speeds up the order process between the customer and the telephonist.
Delivery Costs
Delivery costs are calculated with the use of Client-Side JavaScript. The Shipping drop-down list on the default.asp page contains the various shipping methods and prices available. Server-side scripting was not used for this because in order to automatically recalculate the final total; (which is the sum of all products and the selected delivery method) would involve reloading the page. Reloading the page resets the values in the form’s text fields.
VALIDTION
The Author has researched into the mathematical algorithms of ISBN and EAN 13 codes. After analysing the research material that has been included in the Reference / Bibliography section, the Author has written VB Scripts that incorporate the mathematical algorithms to validate both the ISBN and EAN 13 codes Please note that a lot of thought has been put into the development of the these scripts. For example, allowances have been made in programming the script to allow the telephonist to enter the ISBN code with or without the “-“, hyphen.
Fields other than the ISBN and the EAN 13 have the use of regular expressions to perform validation.
DATA VIEWER
XML documents that have been created are displayed on the history.asp /Administration page. The user can view these XML documents by clicking the “View” hyperlink adjacent to the respective XML document. Please refer to the history.asp /Administration page in the ‘Screen Shot’ handout section and the ‘Data Viewer’ section for more information.
All the XML documents that are created by the Author’s web application confirm the Author’s DTD document and utilise the Author’s XSL document for display. The DTD and the XSL documents have been attached to this report.
GENERAL
The history.asp file located in the Ass2 directory on the floppy disk; provides all the links to all files. Additionally, you may access the history.asp by opening the default.asp page and by clicking the Admin button.
Where XML Files Are Created?
XML documents are created in the same directory as the default.asp page. The main reason for this is due to server permission errors the Author has encountered during the testing phase of the web application development. Generally speaking, Internet Information Server prohibits files to be created ‘anywhere’. For more information please refer to the ‘Directory Structure’ document that can be found in the ‘Design and Structure’ handout.
Developing the Web Application Further
The Web Application has been developed further to give the telephonist the ability to modify existing XML files. Customer details may change from time to time. In order to cater for this need, there has been the basis for developing the feature to modify XML files. Please refer to the “Default.asp – Opening an XML Document” in the ‘Data Flow Diagram’ attachment for more information.
Error handling has been designed into the web application to prevent Internal Server errors from occurring. Please refer to ‘Errors Occurred’ and the ‘404 Page Not Found Error’ in the ‘Screen Shot’ attachment for more details.
Problem(s) and Solution(s)
Problem with the Date
New XML File
When a new entry is created, the telephonist specifies the current Order Date. The Order Date must be identical to that of the current system date. The current System Date is the date which appears on the telephonist’s computer.
For example; when the telephonist is on the phone to a customer taking order details, he/she would enter the respective order information. If we were to assume that the current System Date is 01/06/2003, logically the telephonist must also enter exactly the same date in the Order date field. Should this procedure not be followed, a validation error will occur.
The Author is of the opinion that orders which are taken over the phone and entered into the web application whilst the customer is on the phone, should also allow the order date to be validated accordingly to that of the current date.
The Author is of the opinion that in order for the above aforementioned procedure to work both correctly and effectively, the telephonist must enter the order information into the system right-away and not at a later date.
Modifying an existing XML File
When an existing file is modified, the order date does not have to be identical to that of the current system date. Since the application has loaded a file into memory; it temporarily stores the date on the file in a hidden text box on the page. The hidden text box acts as a modified date for the current file on screen. This will preserve the original order date on file. Please refer to the ‘Solution to the Date Problem’ in the ‘Data Flow Diagrams’ section for more information.
Conclusions and Recommendations
No solution is always perfect, thus there is always room for improvement. It would have been more useful to know specific details of the larger system for which the web based order form is a part of. This would mean that assumptions do not have to be made and an exact solution can be implemented.
Attachments
1. Directory Structure
2. DTD Source
3. XSL Source
4. XSL Source
5. date problem
6. pseudo creating xml document]..
7. pseudo loading an xml documen..
