On Tue, 2005-08-02 at 21:31 -0500, Aleksander Slominski wrote: > > > > > why not to follow XML model and in particular XML infoset? SOAP > envelope is EII so it can have DII as parent and DII contains all this > stuff including declaration, encoding etc - see: > http://www.w3.org/TR/xml-infoset/#infoitem.element > "(...) [parent] The document or element information item which > contains this information item in its [children] property." > > it looks to me like a clean and elegant solution to the problem ...
The problem is that there's no DII in all SOAP situations; for example a TCP stream can send one SOAP envelope after another without sending the XML decl over and over. We can create a DII arbitrarily but that's essentially what the message context is isn't it, but with more flexibility than the responsibility to be the DII. Having it in the MC allows us to keep a flag there indicating whether to write the XML decl or not, allows us to set a different charset etc.. For example, its perfectly feasible to have a Web service whose input is in UTF-8 and output is in UTF-16. That info would have to be stored in OperationContext ... and pushed up/down to the two message contexts involved. A single SOAP DII doesn't help there (?). BTW what would you call the DII you're proposing? OMDocument or SOAPMessage? [Eran et al.: What's the interface OMDocType for? The name doesn't follow the Java naming conventions ...] Sanjiva.
