> Sorry, but the extraDataType is a sequence of xsd:any

Correct - it is an sequence of xsd:any's i.e. a sequence of any XML
element nodes - however the scheme does not permit a text node directly
under extraDataType only element nodes (xsd:any references element nodes
only).

Compare the definition of extraDataType:

  <xsd:complexType name="extraDataType">
    <xsd:sequence>
      <xsd:any namespace="##other"
          processContents="lax"
          minOccurs="0"
          maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>

With the definition of stringOrXmlFragment:

  <xsd:complexType name="stringOrXmlFragment" mixed="true">
    <xsd:sequence>
      <xsd:any namespace="##any"
           processContents="lax"
           minOccurs="0"
           maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType

It is that mixed="true" parameter in the latter definition which permits
the string encoding.

> and the code
> generated by WSDL4J leaves me with a choice of how to encode the data.

Yes, that's because WSDL4J doesn't perform 100% XML Schema validation
for xsd:any - basically when it hits xsd:any it goes "right, that's up
to the programmer to sort out" and generates the same "do it yourself"
code more or less regardless of the rest of the xsd:any parameters. So
in this particular case when WSDL4J , yes, you could use the generated
code to create a string under extraResponseData. However if you then
validated the generated XML against the schema it would fail.

> It's okay to say that we have an agreement that the encoding will
> always
> be "xml", but I'm afraid that the schema does not enforce this.

Sorry, whilst the generated WSDL4J code may not, the schema itself does!

Matthew