Bug 56479 - Hardcoded dcterms namespace prefix name in the check for OPC compliance
Summary: Hardcoded dcterms namespace prefix name in the check for OPC compliance
Status: RESOLVED FIXED
Alias: None
Product: POI
Classification: Unclassified
Component: OPC (show other bugs)
Version: 3.11-dev
Hardware: PC All
: P2 major (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-01 16:55 UTC by Sebastien Schneider
Modified: 2015-08-11 05:40 UTC (History)
1 user (show)


Attachments
opc archive to reproduce this bug (1.25 KB, application/x-stuffit)
2014-05-01 18:55 UTC, Sebastien Schneider 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastien Schneider 2014-05-01 16:55:14 UTC 
I've an issue when parsing generated OPC document that use a dcterms prefix different than 'dcterms'. 

For instance 'dc' is used and I get org.apache.poi.openxml4j.exceptions.InvalidFormatException: The element 'created' must have the 'xsi:type' attribute with the value 'dcterms:W3CDTF' because of this different prefix name.

In file PackagePropertiesUnmarshaller.checkElementForOPCCompliance() line 372 you should build the xsi:type string to check by taking into account the namespace prefix name currently used.
Comment 1 Nick Burch 2014-05-01 18:43:17 UTC 
Any chance of a sample file which shows the problem, and ideally too a patch and a unit test? :)
Comment 2 Sebastien Schneider 2014-05-01 18:55:32 UTC 
Created attachment 31582 [details]
opc archive to reproduce this bug

opc archive to reproduce this bug which is located in core.xml file.
Comment 3 Sebastien Schneider 2014-05-01 18:58:25 UTC 
I attached an empty sample opc archive file to reproduce this issue and to help to code a unit test.

I've no time for now to install a dev env for POI ooxml to test a patch but I think that the fix is quite simple to implement (3 to 4 line of code I guess).

Thank you for your help.
Comment 4 Dominik Stadler 2015-08-11 05:40:59 UTC 
This is fixed via r1695212, we now compare against the namespace-prefix from the element.