freelanceprogrammers.org Forum Index » XML / XSL
ODF and content management
Joined: 13 Jun 2003
Posts: 39
ODF and content management
Referring back to the Mad Penguin article, I noticed on
page 2 that the ODF Technical Committee (TC) included the
big content management players like Documentum and Stellent.
http://madpenguin.org/cms/html/62/5304.html
This got me thinking about the role of content management
in a theoretical ODF-based documentation shop. As most of
you probably know already, an ODF document is simply a ZIP
file containing a bunch of XML and graphic files. I just
happen to have an 11-page documentation plan I wrote in
NeoOffice, so I cracked it open with unzip & this is what`s
inside:
Length Date Time Name
------ ---- ---- ----
30 10-07-05 13:47 mimetype
4096 10-07-05 13:47 Pictures/blahblah.jpg
107 10-07-05 13:47 layout-cache
81474 10-07-05 13:47 content.xml
58904 10-07-05 13:47 styles.xml
1189 10-07-05 13:47 meta.xml
56300 10-07-05 13:47 settings.xml
974 10-07-05 13:47 META-INF/manifest.xml
------ -------
203074 8 files
(I replaced a long string of numbers with "blahblah" to
avoid breaking margins.)
I`ve done this before, but not with a content management
scenario in mind. It should be painfully simple for a
content management system to assemble an ODF document from
individual pieces: a styles.xml file could be standardized
to prevent people from mucking around with it -- and I
could see good reasons to have a standard settings.xml
as well -- graphics can be pulled in as needed, and all
you would really need to worry about is content.xml and
(optionally) meta.xml. Everything else could be built on
the fly (manifest, mimetype), pulled from standard pieces
(styles, settings), or from the database of actual content
(content.xml, Pictures/*).
This in itself overcomes one of my stylistic objections
to ODF -- that graphics get copied in rather than imported
by reference. The content management system resolves the
references, inserting graphics from its database (so the
next check-out updates them for you). It also has the
advantage of automatically bundling graphics so you don`t
have to remember to bundle them up yourself to (for
example) send to a translator.
The content (content.xml) has enough structure to give
XSLT something to latch onto... going between OOo and
DocBook and TEI (not to mention XHTML) has already been
demonstrated. So a content management system could take
content built on some other DTD, transform it to ODF as
needed, and bundle it all up on the fly (assuming a good
transform has already been written!).
I`d like to see what people using (or deploying) a CMS
have to say about this... after all, I could be huffin`
the crack pipe again, or missing something obvious.
--
Larry Kollar, Senior Technical Writer, ARRIS CPE Products
"Content creators are the engine that drives
value in the information life cycle."
-- Barry Schaeffer, on XML-Doc
Joined: 08 Feb 2005
Posts: 8
ODF and content management
Hi Larry
I`ll play :)
I think this could work as an entry level CMS application (it might even be
done as just some scripting on top of a simple access control and versioning
application such as CVS). I haven`t played around with ODF much yet as I am
primarily involved in heavily semantic XML and I`m not sure ODF would give
me the depth I require.
One thing I do like about this idea though is that it allows the final act
of publishing to be done with a publishing tool rather than trying to
transform and publish the content using FOP, FO, or the like (which is
damned hard and doesn`t give you really professional results).
Not sure how this would elegantly deal with conditionals though which would
be the killer for most of my clients.
-Melanie
On 15/10/05, Larry Kollar <larry.kollar@...> wrote:
>
> Referring back to the Mad Penguin article, I noticed on
> page 2 that the ODF Technical Committee (TC) included the
> big content management players like Documentum and Stellent.
>
> http://madpenguin.org/cms/html/62/5304.html
>
> This got me thinking about the role of content management
> in a theoretical ODF-based documentation shop. As most of
> you probably know already, an ODF document is simply a ZIP
> file containing a bunch of XML and graphic files. I just
> happen to have an 11-page documentation plan I wrote in
> NeoOffice, so I cracked it open with unzip & this is what`s
> inside:
>
> Length Date Time Name
> ------ ---- ---- ----
> 30 10-07-05 13:47 mimetype
> 4096 10-07-05 13:47 Pictures/blahblah.jpg
> 107 10-07-05 13:47 layout-cache
> 81474 10-07-05 13:47 content.xml
> 58904 10-07-05 13:47 styles.xml
> 1189 10-07-05 13:47 meta.xml
> 56300 10-07-05 13:47 settings.xml
> 974 10-07-05 13:47 META-INF/manifest.xml
> ------ -------
> 203074 8 files
>
> (I replaced a long string of numbers with "blahblah" to
> avoid breaking margins.)
>
> I`ve done this before, but not with a content management
> scenario in mind. It should be painfully simple for a
> content management system to assemble an ODF document from
> individual pieces: a styles.xml file could be standardized
> to prevent people from mucking around with it -- and I
> could see good reasons to have a standard settings.xml
> as well -- graphics can be pulled in as needed, and all
> you would really need to worry about is content.xml and
> (optionally) meta.xml. Everything else could be built on
> the fly (manifest, mimetype), pulled from standard pieces
> (styles, settings), or from the database of actual content
> (content.xml, Pictures/*).
>
> This in itself overcomes one of my stylistic objections
> to ODF -- that graphics get copied in rather than imported
> by reference. The content management system resolves the
> references, inserting graphics from its database (so the
> next check-out updates them for you). It also has the
> advantage of automatically bundling graphics so you don`t
> have to remember to bundle them up yourself to (for
> example) send to a translator.
>
> The content (content.xml) has enough structure to give
> XSLT something to latch onto... going between OOo and
> DocBook and TEI (not to mention XHTML) has already been
> demonstrated. So a content management system could take
> content built on some other DTD, transform it to ODF as
> needed, and bundle it all up on the fly (assuming a good
> transform has already been written!).
>
> I`d like to see what people using (or deploying) a CMS
> have to say about this... after all, I could be huffin`
> the crack pipe again, or missing something obvious.
>
> --
> Larry Kollar, Senior Technical Writer, ARRIS CPE Products
> "Content creators are the engine that drives
> value in the information life cycle."
> -- Barry Schaeffer, on XML-Doc
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
[Non-text portions of this message have been removed]
All times are GMT
Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Freelace Website Designer - Customer web design and software building.
Booking Calendar - reservation calendar script
Land Surveying - total station instruments and equipments
China Wholesale - Electronics Products
Character Studio - Tutorials and Help
Booking Calendar - reservation calendar script
Land Surveying - total station instruments and equipments
China Wholesale - Electronics Products
Character Studio - Tutorials and Help