DIME's WSDL Binding and Unencoded Binary Message Parts

Mike,

In the "WSDL Extension for SOAP in DIME" [1], I'm confused by the somewhat
contradictory specification of the binary data in the secondary message
components - it shouldn't be encoded, right?  Just binary data - neither
base64-encoded nor hex-encoded?

I come to this conclusion because:

* Both layout types (closed and open) specified in Section 4.1 state that
the "content of the secondary message parts MUST NOT be base 64 or hex
encoded."

* Bob Cunnings, who's looked at DIME much more closely than I, says
so:  "Note that the data is not actually hex or base64 encoded when sent
as a DIME attachment" [2]

Yet there are other parts of this description of WSDL binding for DIME
that could give the reader the impression that the binary data should be
encoded (either base64 or hex):

* In the abstract: "describe the encapsulation of a SOAP message with
base64Binary and/or hexBinary content in a DIME message."

* In the introduction: "Message content with the type base64Binary or
hexBinary is serialized as a secondary message part ...".

* In Section 6.1 ("The content:type element"): xs:restriction [3] (not
xs:extension) is used in the discussion.  The value space of
binary64Binary (65 values out of 256 possible values of an octet) is more
restricted than the value space of unencoded binary data (all 256
possibilities).  Shouldn't one extend the xs:base64Binary primitive type
to express unencodedBinary?

Jim Stearns
HP

[1] http://gotdotnet.com/team/xml_wsspecs/dime/WSDL-Extension-for-DIME.htm
[2] http://discuss.develop.com/archives/wa.exe?
A2=ind0205a&L=dime&F=&S=&P=935
[3] http://www.w3.org/TR/xmlschema-1/#key-typeRestriction