Steve T integrated this into one of the latest drafts.

These are comments from Karl relevant to this issue:

I think the question about our use of XML for serviceData comes down
to a need for extensions to XML Schema, just as we needed extensions
to WSDL.  Once you accept that extensions are necessary, the only
question is how best to achieve them.

As I recall, there were several approaches to extension discussed in
the working group:

   1. (what is in the current document) Define a new mechanism
      parallel to XML Schema's element declaration to define
      serviceData element declarations.  We are using the same
      non-conformant XML Schema fix-point tricks that the XML Schema
      uses to define itself.

   2. Use XML Schema element declarations directly for serviceData
      declaration, adding our extended attributes for serviceData
      cardinality.  I am not an XSD expert, but I recall concerns that
      this could not be done without a new XML Schema specification?

   3. (what was in an early draft) Use XML Schema element declarations
      to declare the content of serviceData elements, and use a
      "service data declaration" to associate this element declaration
      with additional cardinality attributes etc., instead of adding
      these attributes to the element declaration as in (2).

The problem with (3) is that it requires an extra(-ugly) layer of
wrapping around XML Schema elements so that two different service data
declarations can assert properties about the same XSD element type and
these can be distinctly named SDEs in the same service.

Something like:

  (in tns1)

  <gwsdl:portType name="PTName1">

      <ogsi:serviceDataDeclaration name="SDName1"
             elementType="tns2:foo"
             minOccurs="0" mutability="static" ... />
           
      ...
  </gwsdl:portType>


  <gwsdl:portType name="PTName2" extends="tns1:PTName1">

      <ogsi:serviceDataDeclaration name="SDName2"
             elementType="tns2:foo"
             minOccurs="1" mutability="mutable" ... />
           
      ...
  </gwsdl:portType>


Then a service implementing portType tns1:PTName2 could have
SDE values such as:

   <tns1:SDName1>
      <tns2:foo ... />
   </tns1:SDName1>

   <tns1:SDName2>
      <tns2:foo ... />
   </tns1:SDName2>

this wrapping was considered undesireable compared to treating
serviceData as an extension of the element declaration model, as used
in the current document.


karl