[
https://issues.apache.org/jira/browse/COR-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14345239#comment-14345239
]
Dennis E. Hamilton commented on COR-38:
---------------------------------------
I saw a comment on the list somewhere about the parts of an ODF. I wanted to
clarify something, at least for consuming ODF.
The only required components of an ODF Package are, I believe,
META-INF/manifest.xml and a content.xml file. That would be a simple document,
but it is a valid case according to the schema (which I should recheck at
http://nfoworks.org/notes/2014/05/n140504f.htm).
Also, there is a "Flat XML" form of ODF document file which is a single XML
file with no package. The OpenOffice.org descendants use extensions like .fodt
for a Flat ODT, for example. I don't think this occurs in the wild very much,
but attempts to remove this case have failed. These are handy for test
documents and also for computer-generated documents.
The rules for these combinations are found in the ODF 1.2 specification Part 1
section 3 Document Structure. Section 2.2.1 specifies that a package must have
at least one of styles.xml and content.xml. (The styles.xml case was explained
to me with regard to a document that is used as a source of styles, sort of as
a template, but I don't know that any current implementation will produce such
a thing.)
> Create ODF Text filter
> ----------------------
>
> Key: COR-38
> URL: https://issues.apache.org/jira/browse/COR-38
> Project: Corinthia
> Issue Type: New Feature
> Components: DocFormats - ODF filter
> Reporter: Peter Kelly
>
> Along with OOXML (specifically .docx), ODF (specifically .odt) is an
> important format for DocFormats to support. Implementation of this filter
> will involve conversion to and from HTML. The resulting HTML can subsequently
> be used with the OOXML filter (or others), which will enable us to convert
> ODF to and from different file formats, with HTML as an intermediary step.
> I've specifically mentioned ODF Text documents (word processing documents)
> for this issue, as this is what DocFormats is currently designed around;
> support for spreadsheets and presentations are separate issues with a
> different set of tasks/requirements.
> The existing (but poorly documented) Word filter provides a design that could
> be readily adapted to use in ODF. However, the fact that change detection and
> updating are intertwined in the existing Word filter means that this would
> have to be replicated for the ODF filter as well. A possible alternative to
> simply replicating the existing design would be to have change detection done
> entirely separately, and modify the interface for both filters to accept a
> list of changes to apply, rather than an updated HTML document.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)