Detached vs Enveloped
The examples below illustrate the usage of detached and embedded signatures.
Detached signatures
For the sample mapping below, the Detached signature option has been selected. Therefore, two separate files have been generated: (i) the mapping output file called MarketingExpenses.xml and (ii) a temporary digital signature file called MarketingExpenses.xml.xsig (see screenshots below). The mapping MarketingExpenses_DetachedSignature.mfd is available in the MapForceExamples folder.
To generate the .xml and .xsig files in the output directory, click the Save all generated outputs 
toolbar button.
Enveloped signatures
If you select the Enveloped signature option, the <xsig:Signature> element will be integrated into the output file after the <expense-item> (see screenshots above). This feature is illustrated in MapForceExamples\MarketingExpenses_EnvelopedSignature.mfd.
XML document validity
If an XML signature is embedded in the XML document, a Signature element in the namespace http://www.w3.org/2000/09/xmldsig# is added to the XML document. In order for the document to remain valid according to its schema, the schema must contain the appropriate element declarations. If you do not wish to modify the schema of the XML document, use the Detached option (see above).
The code listings below show how the Signature element of an enveloped signature can be allowed. In the first listing, the XML signature schema is imported into the user's schema (highlighted yellow).
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsig="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/>
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element ref="FirstChildOfRoot"/>
<xs:element ref="SecondChildOfRoot" minOccurs="0"/>
<xs:element ref="xsig:Signature" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
...
</xs:schema>
The second option is to add a generic wildcard element which matches any element from other namespaces (highlighted yellow below). Setting the processContents attribute to lax causes the validator to skip over this element, because no matching element declaration is found. Consequently, the user does not need to reference the XML signature schema. The drawback of this option, however, is that any element (not just the Signature element) can be added at the specified location in the XML document without invalidating the XML document.
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element ref="selection"/>
<xs:element ref="newsitems" minOccurs="0"/>
<xs:element ref="team" minOccurs="0"/>
<xs:any namespace="##other" minOccurs="0" processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>