Hi David
...On the other hand, not adhering to a particular encoding provides for
interoperability problems.. Should we also suggest the XML Schema group
encoding model?I think the world can live with a few distinct encoding
models, but not more. This way, various soap processors can accommodate
them. However, if more than a few encoding models evolved, then we have
a serious issue on hand.
Marwan
David Ezell wrote:
>
> At the face to face meeting in Cambridge (February 26 - 27) I agreed
> to begin the discussion of Issue 48 in [1], raised in an email to
> xml-dist-app [2].
>
> <quote>
> R202
>
> "The XML Protocol should allow applications to include custom
> encodings for data types used for parameters and results in
> RPC messages."
>
> The SOAP encodingStyle attribute [5] can be used to used to indicate
> arbitrary serialization rules within a SOAP message. Section 5 [3] of
> the specification also states that "use of the data model and encoding
> style described in [the section describing the default SOAP encoding] is
> encouraged but not required; other data models and encodings can be used
> in conjunction with SOAP."
> </quote>
>
> To my reading, the point being made here is that the XML Protocol
> requirements don't go as far as SOAP/1.1 in terms of defining or encouraging
> special encoding vocabularies.
>
> I would strongly urge that we keep the current wording, and go no farther
> in "blessing" any specific type of encoding. As a possible amelioration
> we should *at most* reference the SOAP/1.1 specification, section 5 [4] as
> a useful encoding for RPC.
>
> Rationale
> =========
> Encoding rules outside those described by XML per se are application semantics,
> and are hence best left out of scope for XML Protocol [6]. Encoding rules
> represent an agreement between applications to interoperate in ways not directly
>
> prescribed or describable by XML Infoset. Additionally, the encoding rules are
> based on older RPC architectures, and are arguably only applicable in situations
>
> which represent ports of legacy services created using COM, CORBA, or RMI.
>
> More importantly, type definitions in XML documents and how they map to
> application programming languages is an issue best left to implementations
> of content model information sets, such as the XML Schema post validation
> infoset. Leaving the issue there helps assure maximum "composability"
> (borrowing Paul Cotton's phrase) with other W3C specifications as well
> as with outside specifications.
>
> Best regards,
> David Ezell
>
> [1] http://www.w3.org/2000/xp/Group/xmlp-issues.html
> [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0193.html
> [3] http://www.w3.org/TR/SOAP/#_Toc478383512 <http://www.w3.org/TR/SOAP/
> [4] http://www.w3.org/TR/SOAP/#_Toc478383512 <http://www.w3.org/TR/SOAP/
> [5] http://www.w3.org/TR/SOAP/#_Toc478383495 <http://www.w3.org/TR/SOAP/
> [6] N.B. the adoption of multi-part MIME encoding is a separate issue,
> as I believe that such encodings are currently viewed as "bindings".