Known issues and limitations

Known issues or limitations that you might encounter in specific system environments, or configurations.

The problems described in this topic might not be limitations with the release. Instructions are provided to work around problems, where possible.

These known issues and limitations also apply to earlier releases:

Unexpected XSLT error on extension elements or extension functions when security is enabled

Any attempt to use extension elements or extension functions when security is enabled, results in a javax.xml.transform.TransformerException error during XSLT processing.

The following XSLT message is generated when extension functions are used: Use of the extension function '<method name>' is not allowed when Java security is enabled. To override this, set the com.ibm.xtq.processor.overrideSecureProcessing property to true. This override only affects XSLT processing.

The following XSLT message is generated when extension elements are used: Use of the extension element '<element name>' is not allowed when Java security is enabled. To override this, set the com.ibm.xtq.processor.overrideSecureProcessing property to true. This override only affects XSLT processing.

To allow extensions when security is enabled, set the com.ibm.xtq.processor.overrideSecureProcessing system property to true. For more information about this system property, see -Dcom.ibm.xtq.processor.overrideSecureProcessing.

Avoiding ambiguity when you define types in schemas

In the following example, elements abc and xyz each define an element that is named foo. The type of element foo is defined but not named:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

  <xs:element name="abc">
    <xs:complexType>
      <xs:element name="foo">
        <xs:complexType>
          ....
          .....
        </xs:complexType>
      </xs:element>
    </xs:complexType>
  </xs:element>

  <xs:element name="xyz">
    <xs:complexType>
      <xs:element name="foo">
        <xs:complexType>
          .....
          .....
        </xs:complexType>
      </xs:element>
    </xs:complexType>
  </xs:element>
</xs:schema>

When a type is defined like this, the schema processor uses the name of the element to generate a name for its type. For example, foo_type0. The next time an element with the same name and unnamed type is encountered, a different name is given to the type to avoid conflict. For example, foo_type1.

The order in which these elements should be processed is not mandated by schema specifications. Most processors, including the one in the SDK, optimize by processing the elements in parallel, so you cannot be sure which elements will get which type names. So in some cases, the foo element within the abc element gets the type foo_type0 and the foo element within the xyz element gets the type foo_type1. In other cases, the result is the opposite. Do not rely on the order in which elements are processed; for example, if the schemas are used to generate Java code, the variable types within the corresponding classes might be different.

Some processors always generate the same type names, but this behavior is not guaranteed by the specification so you should not rely on it.

If the unnamed types for both foo elements are the same, create the type outside the abc and xyz elements and reference it by its name. This method not only avoids ambiguity but also improves performance because the type is not duplicated unnecessarily:

<xs:complexType name="fooType">
  ...
  ...
</xs:complexType>

<xs:element name="abc">
  <xs:complexType>
    <xs:element name="foo" type="fooType"/>
  </xs:complexType>
</xs:element>

<xs:element name="xyz">
  <xs:complexType>
    <xs:element name="foo" type="fooType"/>
  </xs:complexType>
</xs:element>

If the unnamed types are different, use different names for the elements to avoid conflict and ambiguity:

<xs:element name="abc">
  <xs:complexType>
    <xs:element name="foo">
      <xs:complexType>
        ...
        ...
      </xs:complexType>
    </xs:element>
  </xs:complexType>
</xs:element>

<xs:element name="xyz">
  <xs:complexType>
    <xs:element name="notfoo">
      <xs:complexType>
        ...
        ...
      </xs:complexType>
    </xs:element>
  </xs:complexType>
</xs:element>