A Mini XML Revelation
Thursday August 19th 2004
Over a bowl of cereal this morning I was reading through MaxDesign's recent article, A Webstandards Checklist, and of course it led me to daydreaming about my site. My recent desire to move entirely to an XML-backed site has somewhat wained, with the exception of the navigation, and thus overall structure of the site. XML will allow me to implicitly describe the depth and scope of my site by using the power of XML as a structure-oriented language.
My current system, just to give contrast, consists of a series of tab-delimited text files, one for each major section of my site, Play and Work. Each line of a text file represents a page within that section, with each tabbed "column" holding values of different aspects of that page; page title, url, live status, meta data, etc. So, a navigation_play.txt file exists for the Play section, with 6 lines in it; one for the main page, one for the blog page, and one for each of my galleries. The same holds for the Work section. The limit of this system is that it restricts my site to a flat two-levels. If, down the road, I wished to add a subsection to any page within the Play or Work sections, I knew I would have to completely tear down and rebuild how I structured my site. And while I am not quite at the end of that proverbial road, I would rather prepare for the worst now instead of forging ahead with an inherently flawed plan. . .
And so I've been mapping out the elements of each XML node for my new navigation system, which has of course largely been based on the aforementioned tab-delimited files. The base node of my XML file is simply Navigation, which has two child nodes, one for Work and one for Play. Each page within Work is placed as a child node of the Work node, and the same goes for the Play pages. Now, if I wished to add another level of pages to my site, I would merely have to place it as the child of whichever page I want it to be below. Parents, children, children's children, all relationships are implied by structure. Nice work, thank you XML.
Having come this far, I have since been revisiting the elements I've stored for each page (title, url, live status, etc), and questioning which are needed, and others that could be added. And that's when it occurred to me that I should also store any stylesheets specific to that page. The idea was spawned from Dunstan's recent post about his site redesign regarding breaking his stylesheets out by color & images and layout. . .
The content of my site could be placed within 3 broad categories: galleries, posts/articles, and portfolios. Yet the design of the site is contained within one stylesheet, which bloats the XHTML as well as the CSS. If, for example, I wished to style the gallery headers differently from the portfolio headers, I would be forced to using IDs in the XHTML and stylesheet definitions for each ID. Certainly not the end of the world, but not a perfect system either.And if that concept is applied to a much larger site, or perhaps a content management system (my true dream), then the bloating and extra tags would certainly take its toll.
So now the idea is to break out the basic layout of the site into its own stylesheet that would be called from every page within the site; then any variation of section-specific stylesheets could be created and called upon only when necessary. . . Having said all of this, it doesn't sound like an earth-shattering revelation, but every step in the right direction is a good thing. . .
And here's another thought: it might also be helpful to store the "type" of page or section being described. For example, I know that my blog sections will some day need to be better archived (instead of a continuous list of past postings), so maybe if I were to flag that it were an "archive" section, then I could add PHP code to automatically draw out an archive system based on date, section, or however else I'd like it done. Similarly, if I wished to make the giant leap from a dynamic to static site, where I'm writing out site files as they're created, then I would know in what fashion I needed them stored on my server based on the type of page they were related to.