Hello Gregor,
I'm playing devils advocate a little but I really can't see much of a problem
the biggest one: you are maintaining your own data formats, with all it's associated costs.
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 ?
you'd be well advised to ponder whether you might get away by extending xhtml and reusing it's basic building blocks.
a paragraph is a paragraph. a h1 is a h1. I can't see how these can be extended to mean anything.
A restuarants menu could consist of:
<h1>Lunch Menu</h1> <b>soup</b><p>�10</p> <b>pot noodle</b><p>�1</p> <b>fish pie</b><p>�5</p>
but only a schema can describe the elements of "menu type" , "dish" , "price", and the relationships and constraints between each element. The xhtml dtd has nothing to say on the meaning of our restaurants menu.
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.
Lee C
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
