Reasons to Structure

[Paul Nagai]

Matt's question is, to some degree, academic and as a result list members
have made many valid points, some totally at odds with others. (Isn't that
the point of academia? :) In practice, the questions are: What will
structure do for *my* problems and what will it cost to implement?

I said the following recently in response to a similar question about XML
over on techwr-l:

For a long time my XML philosophy was, "If you need XML, you're already
there." I've come off that belief as tools, best practices, and the like
developed and evolved. That said, my current XML philosophy is "Don't deploy
XML unless you have a clear set of goals and objectives and have a good
understanding of the costs (effort, software, hardware, etc.) required to
achieve those goals." In other words, XML for the sake of XML is a time and
money pit. (My old philosophy was so much more catchy! ;(

Find/replace XML with structure and you have my opinion on structure (less
the catchy phrases). You better know why you're structuring your content and
have a deep understanding of the obvious and hidden costs. Then it's just
math ... is there ROI?

-- 
Paul Nagai