[ 
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)

Reply via email to