Heal Your Church WebSite


Teaching, rebuking, correcting & training in righteous web design.

Separation of Data and State

One of the favorite quotes I contributed to Vincent Flanders’ best-selling book (one which I command all my faithful followers to buy and memorize) appears as item #6 on page 279:

“The separation of content and formatting is not in the Constitution, but it should be.”

Mark-up constructs embedded in data such as <font>, often become tedious obstacles for those of us the nerd-programmer persuasion assigned to safely store and later re-render in a variety of physical and digital formats. In other words, if you save hard-coded HTML in your data, then you’ll find yourself having to find or write programs to strip it out things like evil <marquee> tags when you want to publish the same data in some other format, such as PDF or XML.

For those of you that don’t speak pure geek, I’m talking about having the ability to store apples as applesauce, only to later re-constitute it as a pear or a peach; an ability that is hampered when you pollute the sauce with stems and bird-droppings. This is why it is a good practice to separate your website’s data and formatting using CSS; tableless if possible. There are however times when you need to render data exactly as it appears in real life.

A point made by Sean McGrath almost two years ago in an article entitled: ITworld.com – XML IN PRACTICE – Separating Content from Presentation: Easier Said Than Done. Yes, the article does have some dust on it, but it is one of the better articles I’ve found describing some of the complex issues surrounding the storage of highly specialized and/or sensitive data, especially where ‘guestimates’ equal an adulteration of the data as he writes:

“Bitmapped graphics on the other hand, are intimately tied to a particular rendering in terms of pixel area and color depth. Bad things typically happen if you try and resize bitmapped images as the pixels in the image do not encode any semantics about what the image represents. In short, they cannot be repurposed to different shapes, sizes or color schemes without significant loss in quality.”

Is it Live or is it Memorex?

In English, what McGrath is talking about is similar to what happens to the ‘exactness’ of an image when you convert and compress huge images from your digital camera.

Another example of what the author is getting at, at least the heart of his message can be demonstrated in listening to the difference between recording a sermon at 16bit at 44khz stereo versus 8bit at 22khz stereo. The latter being a tinny knock-off of the former. Granted, while this might be an improvement for some of the ‘musicians’ at your church, such variances can actually kill someone when dealing with medical or military imagery.

So now that I’ve scared the mess out of those of you whose physicians are bragging about their latest venture into Java-based web services, let’s keep in mind this article is a couple of years old … nor do I entirely agree with McGrath’s closing argument where he writes:

Yes, it makes sense, for all sorts of reasons, to separate content from presentation. Yes, XML is a great technology for helping you achieve that.

However, sometimes, the medium is an inextricable part of the message. The next time someone tries to sell you a line like “just separate the content from the presentation with XML” be warned — it is not necessarily that simple.

Three Ways to Skin your XML Cat

While I agree there is some data in which compression and/or denormalization is synonymous to adulteration, I also know from my RDBMS upbringing that quite often the best treatment of binary data is just to leave it as is and instead modify the storage and/or transmission mechanism to make exact duplicates. For example, if I want to save the image of a fingerprint, I save it as a binary large object, or BLOB for short. The same mechanism can be used text file using some form of a foreign language encoding; though some will argue in favor of a ‘VARCHAR‘ field.

Regardless of what your religious beliefs are concerning datatypes, a rule of thumb to remember is that there is always more than one way to skin the binary data cat, XML is no exception to this rule. A point well made by an article written two years before McGrath’s entitled “Handling Binary Data in XML Documents” by Lisa Rein. Here she explains two common methods for transmitting medical imagery:

  • external entity and notation;
  • MIME data types.

I won’t go into the mechanics of how each of these methods are employed, you can get that from Ms.Rein’s aricle. You can also see these methods further explained in “XML, SOAP and Binary Data,” an article published back in February 2003 that looks at this same problem in practical terms of web services. So does the chapter on SAX in the Java™ Web Services Tutorial.

But Dean, didn’t you mentioned “three ways” to get this done!?

Why yes I did, and I’m glad you asked. The third method deals more with text and one in which I made reference to in my 14-Feb-04 post “the Gospel, according to RSS and/or Atom” when I wrote:

Finally, we either needed to encapsulate the RSS::<description>, Atom::<content> with <![CDATA[ ... ]]> to accommodate the hyperlink to the audio rendering, or figure out some way of listing the audio version as an alternate link.

Just in case you need some help connecting the dots – or bullet points to be more concise – one way you can address the “Table” issues mentioned by McGrath is to:

7 Comments

  1. Although mostly philosophical, this was a very informative article. I get comfortable with a certain method of doing things, and I almost feel that tables, non-breaking spaces, and other various HTML tricks that have developed over time are my life line when developing websites.

    I am webmaster of a Christian website, Swing the Sickle Productions, and I am currently redesigning the website. Swing the Sickle produces Christian videos. We have our biggest video coming out this Fall. I’m trying to have the new design ready to launch at the same time.

    I have finally broke with my old methods. I am writing the new website completely in XHTML 1.0. I am going to try and avoid the tag and the tag in most instances. I am creating several CSS 1.0 external style sheets. My main goal with the new design is modularization.

    If the navigation is a separate entity from the content, then I will only have to change the navigation in one place instead of changing it for every page when I change something. I know the tools to do this have been around for a while, and I am just now getting around to it, but I have a hunch that I am not the only one. I am sure there are a lot of other webmasters out there tied to their HTML and tables. Now just might be the time to make the jump to XHTML.

  2. I *really* appreciate this blog. I’m sort of a geek wanna-be: a church staffer who supervises communications strategy and implementation, but doesn’t implement everything myself for the parish.

    I do have a personal ministry website, though; right now, it’s just my weekly blog on upcoming readings in the lectionary, but I’m planning to migrate my sermon site and other resource pages there.

    When I designed the site template (and I’m not a web designer; I’m a biblical scholar, so please be gentle), I did it initially using CSS, not tables … but I came across a good number of web pundits who said that tables are far more likely to display across a variety of browsers, and my initial experience with asking friends to view a draft template bore that out, as layers that were supposed to be distinct from one another overlapped, and layers that needed to overlap were staggered. I would have purchased a good book on CSS and spent time trying to fix that, but I decided instead that the pundits saying “go with tables” probably had a point. I seem to recall that there were some accessibility issues associated with a CSS layers-based design as well, but I may not be remembering correctly.

    Now I’m confused. Could you say a little more, for the benefit of the intelligent but novice designer, about CSS vs. tables for layout?

    Many thanks for this important ministry you have with Heal Your Church Website!

    Dylan

  3. Dylan, I liked your website, but I’m trying to figure out why going to your actual domain name sarahlaughed.net redirects to sarahlaughed.net/lectionary-blog.html. Why don’t you just rename lectionary-blog.html to index.html so the visitor doesn’t have to be re-directed?

    As for you question, CSS or tables? It is one I’m struggling with also. I have always used tables for my layout. When I began designing websites in 1998, and I just saw bits and pieces about CSS while I was learning web design. As the years went by, I saw more and more information about CSS. I have never been confident enough with CSS to switch from tables to it until now.

    My website is still table based right now, but I am in the middle of a behind-the-scenes redesign that does not use tables. I will try to keep you posted on how it goes. Most browsers support full-featured CSS now. Curious: when did you design your website? If it was more than a year ago, I think tables were probably still the standard. I too heard the maxim that most major websites don’t have one letter outside a table. I think that has changed, but just very recently. Nest time you plan to redesign your website, I think you will find that the tools to create a tableless design are now available.

    The most important thing in making it compatible is making sure you follow the W3C standards for whatever version of CSS you want to use to the letter. I recommend using CSS 2.1 because its positioning is greatly enhanced from 1.0.

  4. Matthew,

    Thanks for your comments. I have http://www.sarahlaughed.net redirecting to the lectionary blog rather than being the page for the blog itself because I plan to migrate my sermons site and other resource pages to the sarahlaughed.net domain as soon as I can. At that point, the index page will be a true home page, with an overview of what’s on the site, my bio, and such. The lectionary blog gets a fair amount of traffic and a lot of people link to it, so when I purchased my domain name and gave out the new URL for the blog, I wanted it to be a permanent URL, not one I’d want to change as soon as I finished designing the rest of the pages for my site.

  5. What, make separate versions of stuff for print and web use? Why not simply print the church bulletin to PDF and post it on the website?

  6. As Jakob Nielsen says, PDF is unfit for human consumption. PDF is good for printing, but not very friendly for online presentation.

  7. During the redesign of our site at the beginning of the year, I first started out with a completely tableless site. After testing on several browsers on Mac and PC, I found that there were always issues with the display, but when I started using more tables, I was able to get the display to look consistent across browsers and operating systems. Until everyone seems to agree on how to display divs, I think that table-based layout is the best way to go, but use CSS for all/most of the display of those cells, rows, and columns.