Design Explanations for

Data Structures and Sources

This project comes with all kinds of data - unstructured with regards to stock long-stored in the garage, employees, and store details as well as structured with regards to the shipment and product catalogs. How did I organize all these heterogenous sources of data for my business? I first looked at already existing data structures in these sources and determined any mapping of categories. The elements 'Plant' with its attribute 'ID' in the bill of lading, 'ID' with its attribute of 'Num' in the product catalogs for coleus, begonias, and dahlias, and the 'id numbers' for the old stock of roses, daffodils, daylilies, and tulips map to the same category. 'Text' in the product catalogs and 'description' attached to the old stock refer to the same category but not 'Description' as used in the product catalogs. 'Name' regarding the old stock and 'Name' in the shipment document map. 'Type' high up in the hierarchy in the product catalogs maps to 'Type' down in the hierarchy of the shipment document.

In the real world where there's more heterogeneous data sources than what is provided for this project, one should map these categories into one structure using some programming code (where Plant ID=ID Num, merge such and such, etc.) or XSLT transformation, but, at this point in my XML capabilities, I chose instead to manually map the elements. The semantics used are different but I chose the element/attribute names already used in the majority of the structured documents (e.g. ID/Num and Text). I mapped Plant/ID to ID/Num and drew the corresponding names from the shipment into the 'Name' element I created for the product catalogs. I created XML documents for old stock using the same structure as used in the product catalogs plus the elements 'Qty' for stock on hand (with attribute 'Type' to denote its form - bulb or plant), and UnitPrice. These last two elements are not included in the XML documents for the product catalogs (they should be) but I have not done so at this point. How do XML tools deal with elements having no values? (For now, I put 'none' for one dahlia that has no corresponding name in the shipment document.)

I have also created separate XML documents of company data (one for contacts and business hours and one for employees). I decided to create separate documents for these as well as for each of the flower types because I anticipate the business to grow and keeping them separate will make it easier later for updates, inserts, and transformations unique to each type. But as we have learned in this class, one can put together different XML documents into one source XML document and then use the 'document(@)' function to extract data from these sources. I chose to follow this strategy and I have used one source document containing all my individual XML documents as my sample XML document attached to different XSLT documents.

Alongside the data provided for this project, I also have downloaded flower images from the Web [see picture credits at the bottom of this page] and have created/conceptualized my business logo/slogan.

Drawing Out and Presenting Data

Now that I have my data structures set in my XML documents as well as images and logos, it's time to put data values into presentational structures like Web pages using a combination of XPath, XSLT, CSS, JavaScript, and good 'ol HTML. This is where the fun (or the cursing) begins. I always find it a huge challenge to throw things together to produce something that the user can finally interact with on a user interface like a Web page. I found it necessary first to make drawings on paper on how I would lay out the data elements and attributes so I could construct XPath statements that will best draw out the data values from my XML documents and the HTML structures that will best display the data values on my Web pages. I also used the layouts to determine what elements of complementary tools like CSS and JavaScript I can use.

The biggest frustration that I have had to deal with at this stage is the realization that although digital tools make it easier for us to create several views of the same underlying data, I find that we are still very much constrained by linear structures. It makes for leaner, cleaner coding to use XPath statements that will handle repetitions to populate a series of cells in rows or columns of tables in HTML. In most of the pages that I have created for the individual flower types, this worked out well. Flower types with only three data groupings to display were best displayed in one single horizontal series. Those with more than three in one single vertical series. It was also easy to loop through different data elements of the same flower type and present these in a table as I did with the roses. But the homepage presented the greatest challenge because I wanted to arrange image and text links to each of the flower types in a layout other than a single vertical or horizontal series, either of which I thought ugly for a homepage. Three cells in top row, one cell (with two empty cells) in middle row, and another three cells in bottom row. I first tried to see if I can use XPath statements that can loop through the first three flower XML sources for the first row, target the fourth for the second row, and loop through the last three for the bottom row. It didn't work and I didn't have the patience to look up the right coding. Placing the looping codes outside of the row tags and the conditional and select statements in the cell tags draw out the data values but do not display them well. I ended up putting all repetition, conditional, and select statements for each of the seven cells in my preferred arrangement. There's probably a leaner way to code it but I thought that in the real world, the homepage is usually used to feature only a select set of products or items and the rest are displayed in linear structures on the side. I almost used just HTML to handle this design which required far less code but I know that this will not do well when my business grows and I have to select from a bigger store of data.

Other Components

I have used external CSS stylesheets because it will be easier to make changes in one source than in individual pages. I have also used external JavaScript files to handle some functions particularly in showing the contact and business hours information in new windows in the sub pages. For my homepage, I have drawn out these information from my XML source for company info but for my sub-pages I have decided to store these in JavaScript functions in an external file that I can refer to and call from any of my subpages. This required fewer lines of code but now I'm realizing that it's probably these external JavaScript functions that make Internet Explorer unable to display my html files transformed from XSLT files. I will be fixing this problem soon. [It's fixed but now the problem in using JavaScript that opens a self-referential new window forces me to use a different stylesheet for each of my flower pages even they share pretty much the same structure and components. Although I have put all the individual XML files into one, having a separate XSLT for each of my pages doesn't exploit the full potential for re-use. I will be changing my design in Part 2 so that I will only use ONE or two XSLTs.]

I will also be learning in the coming weeks how to output XML documents, particularly those containing my business and employee details, in formats other than Web pages, such as Word, Excel, or PDF documents. Lots more to learn. There are questions to answer how all these are changing the way we will have to deal with information and the objects that carry or bear them. Perhaps I will really have to rethink the distinctions that we in LIS hold so steadfastly between bibliographic systems of information organization and the rest of organizing systems out there in the world (e.g. the rest deal with 'physical things' while we in LIS deal primarily with thoughts and ideas embodied in documents). Hmmmnnn...gotta smell the flowers for now.

My XML and XSD files

Picture Credits