Here is a fundamental truth; long reports written for the page are not appropriate for the web. The best content is written for the web, by good writers. These days, almost any web site that mixes up this idea ("It's all content right?") is doomed to being boring and unsuccessful. And this crucially effects how you build a CMS. Because it means you still have to offer the ability to download those boring... er... scintillating reports. But you have build a way to write content to a website - and as far as I know, everyone does this by using web forms.
In terms of publishing, I've seen people use a CMS to do 2 basic things. System users usually log in and then paste a report they've written in Microsoft Word into a field, and that report becomes the top story on the news page that day. This is relatively dynamic content - it can change every hour, or every day, and it's basically stored in the database as text. The other way they publish is they go and upload a physical file, like a pdf, or a video, or a document. This is what I call an asset'. This gets stored in the database in its original form.
What the browsing public reads on the site is the news story that has been pasted into the field in the administration screens. So they'll read the latest news, and at the bottom of the story it might say "For more information on how to inflate rubber pigs, download our 33k pdf file here". When they click there, they will get the PDF file, which they can save or read through their browser.
So, in a way, a CMS is partially about creating screens that will allow people to publish content to a web site, and partially about creating a system that can handle resources such as documents, videos, sound files and graphics. You could call that a digital asset management system. The real trick is getting these two things to work flexibly together, and yet make each part do what it does to the best of industry standards.
But publishing isn't the end of the story by a long shot. From the perspective of the system users, the other side of a CMS is the finding of content. If you are running a medium sized site, with news changing say everyday, you are going to be creating masses of content. Finding it afterwards is the trick. And you will always need to go back and find and edit stuff you've published. (And I think we should aim for medium sized here folks, or higher, because we aint no two bit operation.)
Most importantly, and here is where the getting the CMS and the asset management stuff working together' becomes really important; you will need to link news stories together with assets. Say you write a story called "Growing sweet Grass on your window sill". Then you want to go through your archives and associate a picture with it. You remember that 4 years ago you took a picture of some fine five pointed leaves that would do splendidly. You have to somehow find them in the online library of images that you have. Then you have to link this image to your web story. And maybe you want a few more images ... and a video "Stashing the pot plants when being raided" ... and that sound file of you swearing from inside the police wagon... ok, I'll stop now.
As I understand, this type of cross linking of the stuff you have in your database has to be set up from the beginning. You would take a web story, entered in using web fields, then you would associate assets like images and files to it, and then theoretically, you could even associate a template to it. So each news story could have anywhere between 0 - 5 images and files linked to it, and system users could even choose how it lays out. But I get ahead of myself.
The important thing to know is that a CMS needs to handle two types of interaction from system users - uploading files and documents, and the putting of data into web fields. It also needs to be a damn fine and clever little asset handler and offer lots of search facilities.