Issue 31800 - Deletions are placed into the main text flow while converting to FlatXML
Summary: Deletions are placed into the main text flow while converting to FlatXML
Alias: None
Product: App Dev
Classification: Unclassified
Component: sdk (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P4 Trivial
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2004-07-20 22:13 UTC by akrioukov
Modified: 2013-02-24 20:54 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

An OOo Writer document with some changes recorded. (5.51 KB, application/vnd.sun.xml.writer)
2004-07-20 22:14 UTC, akrioukov
no flags Details
The same document saved as Flat XML. (14.38 KB, text/xml)
2004-07-20 22:15 UTC, akrioukov
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description akrioukov 2004-07-20 22:13:41 UTC
According to the OOo XML specification, p. 112, "in both text documents and
spreadsheets, the default document flow of an XML document reflects the current
state of a document. An XSLT stylesheet or any other application that doesn't
acknowledge change traking information, process all insertions into the
document, but doesn't process any deletions".

Well, if I save a document with changes into OOo native format and then use an
unzipping utility to look at content.xml, everything looks as described in the
documentation, i. e. insertions are present in the default document flow,
enclosed between <text:change-start> and <text:change-end> tags, while deletions
are stored separately, so that only their place in the body text is marked with
a <text:change> tag.

However, if I save the same document as FlatXML, in the resulting file *both*
insertions and deletions are present in the same text flow, marked with
<text:change-start> and <text:change-end>. Since that's FlatXML which is
processed by various custom filters, in particular XSLT stylesheets, it is clear
that the resulting file will always contain a mixture of insertions and
deletions (of course if they are present at all) rather than a text
corresponding to the current document state.

To make my explanation more clear, I'm attaching a sample document which has
insertion and deletions, and the same document, but saved as FlatXML. Note that
I used my own version of the FlatXML filter (that's why the document is
indented), but, of course, the version from OOo SDK will produce the same
result, since SAX parser always processes XML tags in the same order.

I'm unsure it is really a defect, but at least I'd like to know if there is a
resaon for such difference between Flat XML and content.xml.
Comment 1 akrioukov 2004-07-20 22:14:45 UTC
Created attachment 16634 [details]
An OOo Writer document with some changes recorded.
Comment 2 akrioukov 2004-07-20 22:15:32 UTC
Created attachment 16635 [details]
The same document saved as Flat XML.
Comment 3 jogi 2004-08-03 07:56:25 UTC
FlatXML-filter is a sample of the SDK and not a supported filter.
Comment 4 jogi 2004-08-03 07:56:47 UTC
selecting correct sub component.
Comment 5 akrioukov 2004-08-03 09:59:50 UTC
I suppose you have set a wrong subcomponent. As I've already explained, the Flat
XML filter is not responsible for the problem itself, since it just parses a
previously formed XInputStream. Of course it changes nothing in the XML document
structure. It is clear that the problem occurs before passing the input stream
to a filtering component, so that *any* XML-based filter, no matter, supported
or unsupported, will deal with the same stream.

Also note that the Flat XML filter (Java version) shares most of its code with
the standard XSLT filter (in fact, this is the same component with minimal
differences). Since the XSLT filter is a part of the standard distribution, I
suppose it *is* supported. So if you wish you can register a "trivial" XSLT
transformation as an output filter and try to reproduce the problem with it. The
result should be exactly the same as with the Flat XML filter.
Comment 6 jsc 2004-08-03 13:59:47 UTC
move to lo
Comment 7 lo 2004-12-01 11:04:50 UTC
retargetted to later
Comment 8 lo 2007-03-06 16:55:22 UTC
xml filter related
Comment 9 andreschnabel 2007-03-16 17:25:37 UTC
confirmed, as the issue exists in OOo 2.2