Geoff Deering wrote: > 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.
No, no, no -- I never said anything about transforming Word docs. In TeamSite you (the developer/implementer) create an input template, which contains forms to collect the data you want -- it's *not* pasting in a document, it's collecting very specific granular content. > Then there are problems with it not meeting ATAG. I'm not promoting TeamSite; it's definitely not perfect. But it's an *example* of a CMS that *manages content* and leaves the input and output configuration *totally* up to the developer. >> 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. I don't see it as re-inventing the wheel -- it's just customizing it :-) >>> 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. / > Unfortunately that is what most people are used too. > AxKit and Forrest do transform OO docs. People may be used to it, but it's not suitable for input to a content management system; "content" != "document". You *build* documents to specific targets *from* granular content. > 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. I've never even seen one semantically structured. > 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. DocBook was just a public example; the point is the granularity. Use or create a schema to suit the circumstance. Create the input forms to collect the data. It doesn't matter whether it's going to a database or an XML file or whatever -- that part is hidden from the content provider. > 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. Sorry, I don't see it. There are "document management systems" and "content management systems" -- they're not the same... :-) -- Hassan Schroeder ----------------------------- [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. ********************************************************* The CMS discussion list for http://webstandardsgroup.org/ *********************************************************
