Re: DIME's WSDL Binding and Unencoded Binary Message Parts

The interpretation that the data in the secondary DIME records should
not be encoded is correct. I'll clean up the language in the places you
point out.

RE: restriction vs extension for content type. The idea is that you are
describing a restriction on what the binary content is. For example, an
jpeg image instead of any arbitrary sequence of bytes. Using the content
type "pseudo-facets" does not imply that the encoding is changed or that
DIME will be used in the binding.

  =3D=3D Mike =3D=3D

> -----Original Message-----
> From: Jim Stearns [mailto:[email protected]]
> Sent: Thursday, May 09, 2002 5:44 PM
> To: [email protected]
> Subject: [DIME] DIME's WSDL Binding and Unencoded Binary Message Parts
>=20
> Mike,
>=20
> 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?
>=20
> I come to this conclusion because:
>=20
> * 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."
>=20
> * 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]
>=20
> 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):
>=20
> * In the abstract: "describe the encapsulation of a SOAP message with
> base64Binary and/or hexBinary content in a DIME message."
>=20
> * In the introduction: "Message content with the type base64Binary or
> hexBinary is serialized as a secondary message part ...".
>=20
> * 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?
>=20
> Jim Stearns
> HP
>=20
> [1]
http://gotdotnet.com/team/xml_wsspecs/dime/WSDL-Extension-for-DIME.htm
> [2] http://discuss.develop.com/archives/wa.exe?
> A2=3Dind0205a&L=3Ddime&F=3D&S=3D&P=3D935
> [3] http://www.w3.org/TR/xmlschema-1/#key-typeRestriction