Hassan Schroeder wrote:
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.
Can you please define "granular content" for me, and how it's collected?
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 :-)
I think, in general, if you are customising scripts within an
application, and they are designed for that, then that is fine. But in
apps like IWTS you have to write many scripts in their Perl derivative
to get it to clean up a lot of stuff. If you are having to write any
new transformations that aren't part of the core app, that to me is
having to reinvent the wheel (to a very small extent). But I'm more
referring to having to write all these scripts to tie transformations
between applications together.
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.
Can you clarify your definition of content and document.
Can you please also explain your definition of "You *build* documents
to specific targets *from* granular content"?
It would be appreciated.
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.
What is your definition of "semantically structured"?
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... :-)
They might not be the same, so what distinguishes them? Can you please
give clear definitions?
--------------------
Geoff Deering
*********************************************************
The CMS discussion list for http://webstandardsgroup.org/
*********************************************************
