Apache OpenOffice (AOO) Bugzilla – Issue 25562
recht shape with glue points does not conform to DTD when saved
Last modified: 2013-02-07 22:11:34 UTC
* create a new drawing * insert a shape * insert an arbitrary glue point * save the document * unzip the document file, and validate the content.xml with the DTD as delivered with OOo in share/dtd/officedocument/1_0 => the file is not valid relative to this DTD I'll attach a bug doc for easier reproduction of the issue
Created attachment 13200 [details] sample document to reproduce the bug case
will be fixed for oasis format
setting to prio 2 because of file format issue
Christian, since you are already testing for valid files, can you please check if this is still an issue with the relax NG?
clu is right. It is ok in relax NG. But it should be fixed in 7 pp4 and the 2.0 DTD. I send it to you because CL is on vacation.
MIB->CGU: As CL said, this issue is resolved in the current Relax-NG schema. glue points are in fact missing for the OOo DTD. That's the case since OOo 1.0, so I see no justification for resolving this issue in a OOo 1.1.x. One may fix the OOo DTD for OOo 2.0, but that a task that has P4 or P5 rather than P2.
.
reopen to change the owner
Hi Jogi, Please have a look on this Relax ng bug. It's a file format bug and therefore a prio 2 and not a prio 4 or prio5. What do you mean?
AFAIU our definitions a wrong DTD also in OOo 2.0 is the same bug category like a wrong RNG schema. Prio 2 and should be fixed in OOo 2.0 and also in 1.1.5. You need a correct schema/DTD as an external XML developer.
According to jsi This is a prio 2 (fileformat bug) and should be fixed in OOo1.1.5 and OOo2.0. I'm the same meaning. File format bugs should be fixed asap.
MIB: I disagree. IMHO, P2 is only a default priority for validation errors, regardless whether the error occurs for the OOo 1.1 format where a DTD is used or the OOo 2.0 format where Relax-NG is used. When an analysis of the issue showed that the issue is in the schema but not in the file is itself, then the issue is not a file format issue, and P2 is only justified if the schema error effect many/all files. For the validation error described in this issue, the analysis of the issue showed that the issue is in the DTD but not in the file format itself. The analysis showed also that the issue occured already in OOo 1.0, and does not cause any misbehavior. Applying our priorization rules to this issue IMHO leads to P4 or P5.
Flagged "Invalid"
As discussed in the past with similar task, I set this task to P4 and 'OOo later and set it back to mib. If it is possible to fix in OOo2.0 timeframe, than it can be re-targeted. => reopen
reassign to mib