12b
Solution overview
Addressing the functional specification
To benefit its users, the custom solution must add a large amount of functionality to Microsoft Word 2003. I must admit that have found it a huge constraint not being able to design a working solution with Microsoft Access 2003. This is for many reasons. I am very well versed in using the wizards and making full use of its potential and not being able to use these to create effective forms etc, makes the task ahead appear even more daunting. However, I have an obligation to provide a solution to this problem.
Guidance acknowledged
Thankfully, early on I was able to discuss alternative solutions to the problem with my programming lecturer. His initial guidance proved to be invaluable.
Alternatives
One of the alternatives was to make use of the XML smart tags contained within Word. This would mean that all the sermon data would be contained within the actually Word document itself. I could then make use of a search algorithm to look through the document and amend data at my pleasure. Taking this route would be risky and I had a nightmare of a huge Word document containing lots of sermon data chasing me (not really). I was not convinced though.
Notwithstanding that, the idea of involving XML was intriguing. Not being able make use of SQL to query data within a recordset was not longer a big disappointment. It was then that everything started to fall into place. Researching into XML technologies such as XPath and XSLT gave me confidence that I could provide an effective, cheap and complete solution.
The benefits of using XML in this context
The specification's requirements are very demanding. The data must be processed and the solution must output XHTML and two different RSS feeds. It is a matter of fact that XHTML and RSS are actually both XML derivatives. This means that I am able to generate these files using XSLT (XML stylesheets). This makes fulfilling the requirements much easier.
Below is flow chart depicting the main concept behind solution design:
The data is firstly inputted into a Visual Basic form located in a Word document. It is then stored as a XML file using the data structure specified below. Transformation of the XML then takes place and the contents of the XML file is turned into valid XHTML and RSS feeds. These newly created files are then automatically uploaded using FTP.
Storage & data modelling
The custom solution must give full consideration of the need to structure the data appropriately (by using a clear naming convention and data modelling scheme) in order to control unwanted duplication and maximise efficiency. If I were using SQL in Access, I would normalise the attributes to the third normal form. However, I am using XML not SQL and normalising XML is a more complicated affair. Also, the problem does not require the solution to store a vast amount of data that's all interrelated.
I have come up with the following for the final scheme of storage:
<?xml version="1.0"?>
<archive>
<sermon day="DD" month="MM" year="YYYY" time="AM/PM">
<title>Title of sermon</title>
<book>Book of the Bible</book>
<chapter>CCC</chapter>
<beginningverse>VVV</beginningverse>
<endingverse>VVV</endingverse>
<series>Title of series</series>
<preacher>Preacher's name</preacher>
<mp3>URL of audio</mp3>
<ogg>URL of audio</ogg>
<summary>Summary of sermon</summary>
<durationmins>MM</durationmins>
<durationsecs>SS</durationsecs>
<filesize>File size in bytes</filesize>
<datepub>DDD, MMM DD YYYY HH:MM:SS GMT</datepub>
</sermon>
</archive>
The above hierarchial code is valid XML. The data of each sermon will be stored using this format.
Click next to continue...
« BACK | Back to top | NEXT »
