You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2005/08/03 03:20:08 UTC
[Axis2] SOAPMessage
Hi all,
Current source, we have only the SOAPEnvelope that contains the soap
message. But IMO, I think its better to have SOAPMessage as well to contain
XML Declaration, Encoding, etc.,
So that when sending a message transport will get the output from
SOAPMessage.serialize, not SOAPEnvelope.serialize.
Here are the evaluations of other alternations to solve the above problem.
1. put those stuff in message context.
Serializing code is in the envelope and it doesn't have access to the
message context. If someone needs to serialize he must be able to do it
without having a message context.
2. Put this information in OMOutputImpl. This is not practical as we create
a new OMOutputImpl whenever we want to serialize. So I don't think it's a
good idea to have state within the OMOutputImpl.
So what do you all think about this suggestion. This may involve some
changes to the code.
Regards,
Chinthaka
Re: [Axis2] SOAPMessage
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>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.
>
>
i am sorry but i do not follow - why we should optimize for TCP stream?
and if tis is stream why it can not handle multiple XML documents?
moreover optimized serializer for TCP stream can ignore call to XML
declaration ...
>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 (?).
>
>
that is not SOAP DII specific but it is just XML infoset used and XML
decl encoding *should* be checked for consistency with serializer (so
we do not have <?xml encoding="utf-8" ...> and send UTF16) but that is a
separate issue
>BTW what would you call the DII you're proposing? OMDocument or
>SOAPMessage?
>
in infoset element top level element (S:Envelope) may have parent DII.
so serializer can look it up and use it or choose to ignore (as in hypothetical TCP stream).
IMHO if it is XML declaration ti should be specified in XML Infoset and not MC - MC could be used to specify actual serializer and actual stream encoding (transport) as this is external to XML message.
best,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] SOAPMessage
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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.
RE: [Axis2] SOAPMessage
Posted by Eran Chinthaka <ch...@opensource.lk>.
The SOAPMessage I proposed is the DII :-). Basically that will get extended
from OMDocument.
-- EC
_____
From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
Sent: Wednesday, August 03, 2005 8:31 AM
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] SOAPMessage
Eran Chinthaka wrote:
Current source, we have only the SOAPEnvelope that contains the soap
message. But IMO, I think its better to have SOAPMessage as well to contain
XML Declaration, Encoding, etc.,
So that when sending a message transport will get the output from
SOAPMessage.serialize, not SOAPEnvelope.serialize.
Here are the evaluations of other alternations to solve the above problem.
1. put those stuff in message context.
Serializing code is in the envelope and it doesn't have access to the
message context. If someone needs to serialize he must be able to do it
without having a message context.
2. Put this information in OMOutputImpl. This is not practical as we create
a new OMOutputImpl whenever we want to serialize. So I don't think it's a
good idea to have state within the OMOutputImpl.
So what do you all think about this suggestion. This may involve some
changes to the code.
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 ...
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] SOAPMessage
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Eran Chinthaka wrote:
> Current source, we have only the SOAPEnvelope that contains the soap
> message. But IMO, I think its better to have SOAPMessage as well to
> contain XML Declaration, Encoding, etc.,
>
> So that when sending a message transport will get the output from
> SOAPMessage.serialize, not SOAPEnvelope.serialize.
>
>
>
> Here are the evaluations of other alternations to solve the above problem.
>
>
>
> 1. put those stuff in message context.
>
> Serializing code is in the envelope and it doesn't have access to the
> message context. If someone needs to serialize he must be able to do
> it without having a message context.
>
> 2. Put this information in OMOutputImpl. This is not practical as we
> create a new OMOutputImpl whenever we want to serialize. So I don't
> think it's a good idea to have state within the OMOutputImpl.
>
>
>
> So what do you all think about this suggestion. This may involve some
> changes to the code.
>
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 ...
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] SOAPMessage
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi,
Are we to have the XML declaration and charater encoding in the
OMDocument and the SOAPMessage extend OMDocument?
This way we can ensure that when we serialize any OMDocument we have
the XML declaration and char encoding.
On 8/3/05, Eran Chinthaka <ch...@opensource.lk> wrote:
>
>
>
> Hi all,
>
>
>
> Current source, we have only the SOAPEnvelope that contains the soap
> message. But IMO, I think its better to have SOAPMessage as well to contain
> XML Declaration, Encoding, etc.,
>
> So that when sending a message transport will get the output from
> SOAPMessage.serialize, not SOAPEnvelope.serialize.
>
>
>
> Here are the evaluations of other alternations to solve the above problem.
>
>
>
> 1. put those stuff in message context.
>
> Serializing code is in the envelope and it doesn't have access to the
> message context. If someone needs to serialize he must be able to do it
> without having a message context.
>
> 2. Put this information in OMOutputImpl. This is not practical as we create
> a new OMOutputImpl whenever we want to serialize. So I don't think it's a
> good idea to have state within the OMOutputImpl.
>
>
>
> So what do you all think about this suggestion. This may involve some
> changes to the code.
>
>
>
> Regards,
>
> Chinthaka
>
>
--
Ruchith