Some attributes of CTSignatureLine class missing namespace

[jaeksmith]

Issue/Fix

In class CTSignatureLine, the fields { signinginstructions, addlxml, sigprovurl } should each have the namespace attribute set to urn:schemas-microsoft-com:office:office in the @XmlAttribute annotation, as follows:

@XmlAttribute(name = "signinginstructions", namespace = "urn:schemas-microsoft-com:office:office")
protected String signinginstructions;

@XmlAttribute(name = "addlxml", namespace = "urn:schemas-microsoft-com:office:office")
protected String addlxml;

@XmlAttribute(name = "sigprovurl", namespace = "urn:schemas-microsoft-com:office:office")
protected String sigprovurl;

Without this mod, then [ loading, accessing, then saving a docx file ] creates a document where these attributes are lost. (For the signature system we use, this causes system-specific signature block configuration to be lost).

Note: signinginstructionsset (of similar name to signinginstructions) does not need this namespace - it gets propagated properly.

Note: It might be worth checking on whether the attributes { allowcomments, showsigndate } need a namespace also - these did not appear in my files. (All others do appear (and propagate) in my files - so the rest, not mentioned here, don't appear to need modding).

Example

''Attachments'' 😧 available at:
https://drive.google.com/folderview?id=0Byn_MBGknJhUQXlTZVpSUnBaRVk&usp=sharing

Attached are four files:

1. source.docx - manuallycreated / contains a single signature block.
2. result-without-mod.docx - loaded, accessed, saved without the above modification.
3. result-with-mod.docx - loaded, accessed, saved with the above modification.
4. Example.java - a simple app used to generate docs (2) and (3) from doc (1). (You will, of course, need to create/use docx4j jars with and without the mod to test).

If you pull up the document.xml component file of each docx and look at the attributes of the o:signatureline tag, you'll find that the attributes { o:signinginstructions, o:addlxml, o:sigprovurl } in the source document (1) do not appear in result document (2), while they do appear in result document (3). (Note that o:suggestedsigner does appear in all three - this attribute is already annotated with the namespace).

Also attached is a simple app used to test the generate the 'result' docs from the 'source' doc.

Other info:

• docx4j versions: Issue found in 3.0.1; Issue reproduced in current source (3.1.1-SNAPSHOT); Issue fix tested/worked in current source (3.1.1-SNAPSHOT).
• OS: Windows 7.
• IDE: Eclipse Kepler

Thanks

[plutext]

Hi, and thanks for the comprehensive report :-)

It seems there is a disparity between Word's behaviour, and the standard!

vml-officeDrawing.xsd from ECMA-376 4ed contains:

  <xsd:complexType name="CT_SignatureLine">
    <xsd:attributeGroup ref="v:AG_Ext"/>
    <xsd:attribute name="issignatureline" type="s:ST_TrueFalse"/>
    <xsd:attribute name="id" type="s:ST_Guid"/>
    <xsd:attribute name="provid" type="s:ST_Guid"/>
    <xsd:attribute name="signinginstructionsset" type="s:ST_TrueFalse"/>
    <xsd:attribute name="allowcomments" type="s:ST_TrueFalse"/>
    <xsd:attribute name="showsigndate" type="s:ST_TrueFalse"/>
    <xsd:attribute name="suggestedsigner" type="xsd:string" form="qualified"/>
    <xsd:attribute name="suggestedsigner2" type="xsd:string" form="qualified"/>
    <xsd:attribute name="suggestedsigneremail" type="xsd:string" form="qualified"/>
    <xsd:attribute name="signinginstructions" type="xsd:string"/>
    <xsd:attribute name="addlxml" type="xsd:string"/>
    <xsd:attribute name="sigprovurl" type="xsd:string"/>
  </xsd:complexType>

(note the 3 attributes in question are not qualified)

[MS-OI29500] is silent about this:

2.1.1815 Part 4 Section 14.2.2.30, signatureline (Digital Signature Line)
For additional notes that apply to this portion of the standard, please see the notes for pict, §9.2.2.2(a); pict, §9.5.1(a); hdrShapeDefaults, §9.7.2.1(a); shapeDefaults, §9.7.2.2(a); group, §14.1.2.7(a); background, §17.2.1(a).
a. The standard indicates the default value for the issignatureline attribute is true.
In Office, the default value or the issignatureline attribute is false.
b. The standard does not restrict the number of instances of this element.
Office allows at most only one instance of the signatureline element in each place where it can be used.

In my testing, Word 2010 x64 is happy to open a docx containing those attributes, whether they are namespace qualified or not. However, if they are not namespace qualified, it silently drops them on save.

So, your suggested fix looks like the right thing to do, irrespective of the standard.