Joomla is something of a hybrid and not a pure or really close to pure CMS.
Some requirements for sites are common others not so common.
One of the reasons we found Joomla was a search for a hybrid, more a site builder of sorts.
In CMS there are heaps of requirements when one considers "Document Management". I live (and have worked for) one of the kings of this, Xerox corp who are located in my home town.
In order to really achieve proper content management workflow is simply a must have. But, without that... or that aside.
Archival of documents in CMS driven job environments allows setup of a staged flow. So for a news site, the document is live... At CBS it might be section (aka: Headline News, Business Headline etc) for 24 hours. From there it automatically moves to "Yesterdays Headlines"... From there, "This weeks headlines" from there to an archival system.
That archival system is very different from an administrative standpoint .vs. a front end user standpoint. We might need recall that document 12 days later for a follow-up. Thus Archival also is staged, a workflow that is automated defines it. Archiving World News along with say, US Eastern Seaboard weather is unwise. In fact archiving it as "World News" is unwise, it is sub-categorized... Europe, US, Asia (actually more finite than this, but it serves as an example)... So, Sections/Categories/Sub-categories and sub-categories under them. This allows for quick retrieval of keyword/tagged/dated documents for usage by reporters. They can bring up highly focused documents even if they are quite old for reference.
In the front end, news only stays relevent so long in most peoples minds but other forms of sites such as say, engineering may have data that is pretty much always timely. Its archival "signature" and subsequent workflow is wuite different than a piece of news at that same site saying, "New Joomla Book Hits The Market!".
In Document Management every stage we think of in say Joomla as process is actually many, many in multi-user CM of DMS. We think, "archival" where clealy, its EVER so important for sites that over time will attain considerable document material to have it organized both for backend reference/retrieval and front end "easy access" (both by search and logic drill down).
In publishing content again, things can vary. I may have an article that needs publish Eastern Standard Time at 4:00 PM... But a different document need publish at 6AM West Coast time. Again... This is all part of workflow and the document flow signature. I might be a writer, my document needs go to a editor, publisher, art/layout or even one other person who performs all or some of these tasks.
Some documents roll into multiple categorical type classifications but are related. Like, GM Lays Off 400 People but at the same time an article needs go out that is business/political, "Government siezes Bailout inquiries".
Almost any form of information/document management will run into this classification overlap. Commonly what a webmaster will do is say, Well I put it here, or put it there, or put it in both... or make a new category. The result becomes an unmanagable mess as time goes on.
The way it tends to be handled is that the documents are bound, you'll often see this in news stories (related articles). What you dont see is the binding signature in the compu-fluff that makes the association, keeps the association and allows the backend management of those associations, it intertwines through the entire document(s) lifetime, online, in print, archival, research.
If you put it all under one label its "workflow" and workflow is defined via multiple aspects. Human workflow, systems workflow, document workflow.
To put a parallel on it that some folks here might better grasp, take publishing. Not desktop publishing as most of us consider it. But consider just a small firm, advertising firm lets say. They will rely heavily on desktop publishing. There is a "human system" or workflow that brings a concept in the clients minds into a tangible reality, a finished product. There then is the workflow of "keeping it", might be a file cabinet, categorized by client name, a large firm might go by nation client resides in, type of business client, alphabetical order from there. In their folder sits a CD and backup of the electronic versioning, mockups artists created for it, documents of the pitch lines, advertising etc.
Lastly, this ad agency is also responsible for the end advertising. There is going to be a workflow and processes for that. Having a great advertisement and not having a strategy of deployment can make it fail. In the Joomla world, this is out current live content.
Earlier in this thread in the "API Documentation woo-a-thon" Andrew Eddie touched on some of the above in statement. Many here might not have caught it. Making EFFECTIVE use of Joomla is AS IMPORTANT as being able to USE Joomla and thats 110% accurate.
In the case of Joomla... Its not really "CMS" its a site builder with some CMS characteristics. MANY "CMS" systems use the term as its fairly easy to "Grok" for the avg joe/sephine. Over time there has become this complete overlap in terms, CMS/DMS/Portal. When all were conceived they were all quite defined. Overtime the terms get abused, loosened and it becomes a situation of whether your REALLY a CMS or not it is the "buzzword" that has 400 applications feet in the same door. It happens.
In one of the blogagges here I mentioned workflow as its a big bitch with some of our clients.
We have also "rescued" some Joomla sites that over years made their way into "Cluttered, ruined and putrid" (C.R.A.P).
The real question at hand here is CAN Joomla be moved towards some of the above. Really, to try it "Full scale" is just well... Like I said, Xerox Paperless Office I worked on. I worked on this (C.R.A.P) in the financial institutions transitions and insurance networks as small computers "took off".
Its EXTREMELY difficult to stay flexible to EVERYONES possible or every businesses possible needs. One HAS to set boundaries. Programming unlike say marketing has boundaries. Those boundaries can be extended BUT doing so overtime often results in spahghetti (the core knows what I mean).
Going the other way, stretching those boundaries WAY WAY out so in time we could encompass a broader base of possiblilities results in lots of thought, lots and lots of forethought quite possibly (and even likely) that never will be met or for that matter even be in mass demand. In other words, implementing all I noted above which is a highly simplified edition, planning towards that in engineering terms requires a TON (actually 100 TONS) of forethought. Then there is the code, much which would not be implemented in phase 1, 2 or even 50. Then when we get far into it we find, "Welp... we're way ahead of what our average J!User really is"... So... we tossed all this good time away and worse yet we have all this stuff interspersed in code (stubbed, partials etc) and now we got to spend MORE TIME getting rid of it and hopefully we did not tie in too many dependancies!!!!
I *Completely* understand this quagmire.
In Joomla we have indie site builders, casuals, businesses of varying scales all seeking differing things for Joomla to do. Quite different from Ford Motor Company buying the Xerox Paperless Office stuff of years past. We know or have a damned good idea of what they want it for.
We have a zillion hosting firms out there using Joomla as a value added item towards purchasing their web hosting services and/or more.
We have site designers who could not, do not want to have to be engineers in order to make really fantastic sites for clients. We have engineers who want and RECOGNIZE what the designers see and know... but also see that this project really is great work. Thats us and others. We see it as something that can hit "the next level" and we'd like build stuff for it to do just that.
In this workflow stuff the question that FIRST must be asked and defined are WHAT will those document management boundaries be and subsequent workflow boundaries be.
I cant see Joomla as the Online Washington Post. I can see Joomla as the "Washington Political Tribune"... say, ficticious... A staff of 15 reporters, 2 editors, a publisher and a few layout/artwork people and handle it long term to a growth factor of several hundred percent.
I cant see Joomla as Toyota's Intranet management system. I can see it as a tool handling say, Dealers able to locate the exact automobile color, features that they product from another dealership.
ALL aspects however do require some flexible workflows and controlled workflows, human, system, documents.
Just to go back to "homebase" (sorta) on this, I cant tell what can and cant be done unless I spend heaps of hours reverse engineering Joomla.
These are areas our company wants to breach. We have done this type of work and its very (very) well... hmmm... forethought intensive. With this stuff, a screw up in design "bubbles up" to users in very very (did I say very) ugly ways. Thus, The Washington Political Tribune in 1.5 years sits in a situation of literal DOOM .vs. a path of continual success.
Thus for us, understanding J!Guts if its the platform we go with is really really importanto and why the last thing we want do is fight with having to find that information, a treasure hunt.
It is in fact but one project we'd like engage.
Joomla is a good candidate as it is MVC in most regards.
It has a good base of current users and thus testers and people who would benefit from the above type thangs'. In these "site builders" really there are TONS of em' out there, but how many are "making it". Joomla, Drupal, DotNetNuke (Its a portal)... Others have had some acclaim such as e107.
What is needed however is not a CMS, what is needed is a site builder that has strong CMS abilties. All of these named softwares will say, we have this and that and thats all true, well and fine. But none have string "Pure" document/content management abilities but DO have strong site building abilities.
We'd like light the fire under the rest. Joomla is the platform we would prefer. We have existing clients for it, the MVC end of things affords us the ability to use other MVC related work we have done (granted, in ASP.NET) to be moved without having to consider architectural torture.