A Direction for Removing Message&Part, using complexType for most XML types,while allowing MIME multiparts and non-XML datatyping

 
 
 
At the face to face, there seemed to be some interest in reconciling 
the following:
 
1. Removing Message (and Part!) from the wsdl interface definitions 
while
2. Supporting MIME multiparts (or, at least, SOAP with attachments), 
3. providing for nonXML data (the "jpeg case") in attachments,
and also
4. adhering to the use of complexType (and perhaps also group) 
when specifying XML for inputs, outputs, faults.
 
Some other constraints were:
 
Arthur indicated that he wanted item 2, and suggested that doing 2
required
hanging onto at least the "Part" concept. I will call this into question

below.
 
Gudge endorsed being able to use schema complexTypes, etc 
so that they can be used for validation. I intend to try to adhere
to this constraint.
 
Roberto, however, proposed to have a wsdl 
processor use pieces of the complexType to "code for" 
pieces of MIME apparatus or for nonXML data-for example,
by assigning a base64 xsd:type to jpegs.  This seems
to conflict with Gudge's vision of the use of the schema, 
and so deserves careful critical scrutiny.
 
Now, first a MIME packaged byte stream is not even well formed XML. 
Second, it seems somewhat pointless to specify nonXML data (like jpegs)
as 
XML's base64 datatype as part of a complexType.
Possibly this can be done, but its value is unclear --
being valid base64 character data implies nothing about being a valid
jpeg data stream,
not to mention that base64 encoding is not needed on the wire when 
using HTTP for jpegs in their own MIME attachment...
 
As others have suggested, I think the MIME binding (as well as SOAP
enveloping 
of inputs/outputs in SOAP body blocks, for that matter) should all be
described 
within a wsdl:binding element.
 
For example, sending multiparts each of type XML, it should be possible
to reference
multiple inputs, each with a complexType wsdl:type. The binding would
then declare how this
XML grove is spread over the multipart MIME, and the constituent XML
bodyparts. Certainly
this is not an RPC style interface and we should not expect just one
input in the
definition of a multipart to work in the general case.
 
When multiparts of XML and jpeg (nonXMLdata) are being sent, then
likewise multiple inputs 
would be referenced. The input type for nonXMLdata could be handled
according to the agreed upon
extensions for  nonXML datatypes. In keeping with one of the two
extension techniques
that have achieved consensus approval, we could
possibly have an attribute a URL/URI that points to/identifies the
specifications 
containing their MIME content-type registrations.
 
In short, let the functionality of message and parts be provided by
multiple referencing of inputs (and/or outputs and faults, as
appropriate) in the binding. 
By doing this we allow bindings to describe MIME (or DIME or BER or ...)
packaging, 
and do not need a "part "construct in the description of interfaces (the
inputs, outputs, and faults).
Meanwhile bits of XMLschema can be used for validity checks without
being required to
sort out parts of schema that "code for" aspects of  packaging or that
describe nonXMLdatatypes.