> 
> What bothers me with many CMS systems today is that seem to 
> oriented around
> presentation than about the actual content. XML for instance 
> should describe
> the *meaning* of data, not how it should be rendered, it shouldn't say
> <b>Latest news</b>, it should say <headline>latest news</headline>, it
> shouldn't say  <span style="font-family:Verdana;color:red" 
> >08-820951</span>
> it should say <phonenr areacode="08" 
> country="sweden">820951</phone>. This
> gives for infinite more flexibility and possibilities in 
> using the content
> for different purposes.

I'm going to go out on a limb here and argue that's not necessarily the
fault of the vendor. At least in my business (print-based media), people
just don't think in XML terms, so the vendors are just reacting to what the
customer wants.

Yes, in an ideal world, everything would be tagged out the wazoo. But, at
least in my business (print-based media), it's just impossible at this point
to be as fine-grained as you'd suggest. This is not to say some things can't
be done. Newspaper production is based on certain concepts such as headline,
author and body content. In our case, now that we have an XML-based CMS, all
our headlines, author info and article bodies are stored as XML fields that
can be repurposed a gazillion ways. 

The problem, however, comes in the body content. You go try telling our
already very busy copy desk that they now have to spend even more time going
through stories tagging them with things like  "phonenr areacode," etc. -
even if they could, which they likely can't because they're using a "legacy"
print system that doesn't support such granularity (and don't even think of
telling the far smaller Web staff, which does have a modern CMS, that they
have to retrofit every story they get). And don't even think of asking our
publisher to spend six figures on one of those auto-categorizing systems
that claim they could do this.

So what do we do? We compromise. We have a rudimentary taxonomy that we
apply to all our stories and which gets stored as metadata. We supplement
that with a freeform meta keywords field (for things such as company and
product names). In our case, that's enough to do things such as
topic-specific news pages and e-mail alerts. For more granularity on the
user end, slap in a decent search engine, and hope for the best.

Future proofing? Part of that is moving our content into a CMS; part of it
is making sure we replace all those font tags with CSS classes.

Adam Gaffin
Executive Editor, Network World Fusion
[EMAIL PROTECTED] / (508) 490-6433 / http://www.nwfusion.com
"I programmed my robotic dog to bite the guy who delivers the electronic
mail." -- Kibo 
--
http://cms-list.org/
trim your replies for good karma.

Reply via email to