Skip to content

Global/Local element partial interpretation of formDefaultElement="unqualified" #51

@Toilal

Description

@Toilal

Requests generated by soap-client may have missing namespace prefixes on some elements because of a misinterpretation of formDefaultElement attribute.

Please read this source about how elementFormDefault and attributeFormDefault should be interpreted: https://www.intertech.com/Blog/xml-schema-elementformdefault-and-attributeformdefault

elementFormDefault=”unqualified”

Setting this attribute to “unqualified” means all global elements from this schema must be qualified, and all local elements must be unqualified, when used in an XML document.

This article makes a difference between Global and Local elements, but it seems this library doesn't implement this difference.

Here's the WSDL that cause the issue: https://afis.id3.eu/BiometricIdServices/Id3BiometricIdServicePort?wsdl

It's related to an XSD using elementFormDefault="unqualified" here:
http://afis.id3.eu/BiometricIdServices/Id3BiometricIdServicePort?xsd=Id3BiometricIdService_schema5.xsd

With this WSDL, when invoking IdentifySubject action, the generated request is missing the namespace on IdentifySubjectRequest node, causing a SOAP Fault from the server.

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://www.w3.org/2003/05/soap-envelope">
  <SOAP:Body>
    <ns-4c7934d9:IdentifySubject xmlns:ns-4c7934d9="http://biometricid.id3.eu/">
      <IdentifySubjectRequest>
        <data>
          <FingerDataRecord>
            ...
          </FingerDataRecord>
        </data>
      </IdentifySubjectRequest>
    </ns-4c7934d9:IdentifySubject>
  </SOAP:Body>
</SOAP:Envelope>

According to the Blog article, as elementFormDefault is set to unqualified in related XSD and IdentifySubjectRequest is a Global element inside the XSD, it should be prefixed.

When importing this WSDL in SoapUI, generated requests are valid with the namespace prefix on IdentifySubjectRequest and SoapUI can consume the web service properly.

I think this issue belongs to xsd-reader more than xsd2php, because xsd-reader could provide the global/local information on parsed elements, so that xsd2php can use this information to generate JMS mapping properly.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions