Lee Carroll wrote:
who's other data format should we use ? if a standard exists, sure but we're talking individual web content. Each customer has percived unique goals and messages to get across. what are the costs of maintaining these doc types ?
it's a bit like all those institutions that claim to have unique workflow needs and subsequently paint themselves into a corner by customizing a product to death..
a better approach in many cases is a microcontent format that leverages xhtml. http://www.google.com/search?q=microcontent
to stay with your example, you'd make good use of the class attribute and define a fixed number of values
<h1>Lunch Menu</h1> <b class="meal">soup</b><p class="price">�10</p> <b class="meal">pot noodle</b><p>�1</p> <b class="meal">fish pie</b><p lass="price">�5</p>
or even
<b class="meal" id="soup1">tomato soup</b><p class="price">�10</p>
.. you get the idea.
you'd also not use b in the above structure, but that's beside the point.
benefits:
* you get reasonable default rendering without doing anything * the format is useful even without a xsl transform * works with existing tools (dreamweaver anyone?) * allows you to rely on well-understood semantics (p, li, etc)
How can we guide a content editor that a menu must always have a price when they add a dish element etc. This bottom up information architecture allows each content type to be validated against the goals and needs of the page / site. The content authors are restricted /helped in what content is allowed and appropriate. Editing becomes very easy. (Actually I'm over egging the pudding here as its quite easy to produce confusing content structures which are awful to edit, anyway)
To continue with our food theme, garlic bread and doc types, its the future.
arguably for most applications, a lightweight approach as above is enough.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
