Hassan Schroeder wrote:
Geoff Deering wrote:
Sure, that makes sense, but where do you find this CMS?
As I mentioned, Interwoven TeamSite for one (which I've had a
bit of experience with).
I don't think it does all that does it? Not in my short experience with
it. Are you sure it does document transformation from MS Word /
Openoffice off the file system? Everything I saw was just cut and paste
HTML.
Then there are problems with it not meeting ATAG. Accessibility issues.
Just a side comment on it; yet another product that didn't undergo a
proper UAT. The interface components lack consistency in use of
application and behaviour across the whole app.
I think only Lenya/Axkit and Forrest have an architecture that addresses
this, and also "Transit Central" and "Knowledge Tree". But watch the
Forrest mail list and see the pain that people go through to skin their
apps. It's not funny.
I've only fiddled with Lenya a little, not actually deployed it,
and no experience with Forrest.
OTOH, it seems simpler to me to just create a schema (XML or DB)
and write the input forms and output transforms for a particular
application than to implement someone else's one-size-fits-all
solution.
Yes, but why are we caught in this cycle of reinventing the wheel,
constantly? So many developers have to do this.
But I feel that this is the correct approach; to
be able to put Word/OpenOffice docs into the directory structure and the
application transform them into whatever document the system targets,
through XSL or similar approaches.
Actually, that's not what I was referring to -- *no* Word doc I've
ever been given to convert to HTML manually has been formatted in
any kind of semantic way.
Unfortunately that is what most people are used too.
AxKit and Forrest do transform OO docs.
And no document manage system, I'll talking MS Word and OO, collect
enough meta data for the documents or any of their transformations to be
semantically rich. They might end up being semanitically structured,
but not semantically rich.
The approach I'm suggesting is to acquire the content with as high
a degree of granularity as possible. Look at something like the
DocBook (or Simplified DocBook) schema and imagine creating a form
to input that level of detail for a publication.
Though not necessarily each item -- even Simplified DocBook is huge,
and at some point the content providers revolt and storm the castle
with pitchforks and flaming torches. :-)
Yes, I agree with this. But there is also some good arguments that
there are far better schemas than Docbook. Regardless, users will not
want to deal with native Docbook, or any native XML. Geez, I'd never
give a user XMLSpy, unless they were a professional doc writer.
It depends on how successful the new OASIS format is within OO, and also
the Docbook XML filter (import/export). If OO can work as a proper
interface for documents stored and managed in that format, then I think
there are good possibilities.
--------------
*********************************************************
The CMS discussion list for http://webstandardsgroup.org/
*********************************************************
