Re: [i48]: XML Protocol WG Issues list discussion

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".

Received on Wednesday, 21 March 2001 08:42:29 UTC