>> If serialized xml is used (anywhere), one can't ignore the encoding
>> attribute. No?
> Yes, you can. If you only serialize to characters, rather than bytes,
> then the encoding is spurious, because it hasn't been applied yet.
When I said serialized xml, I meant serialized so that it is a
sequence/stream of bytes. XML is a stream of characters; unless it is
converted to bytes, the encoding attribute won't be meaningful.
So, IIUIC, the spec is saying that since it is a Java String (which is
unicode), the 'encoding' attribute, which is used for indicating the
encoding when serializing to bytes, is meaningless and is therefore
ignored. If so, I understand it now. Although, I have to ask, why would
anyone use this attribute in the Java String form? And if they did,
wouldn't this be an indicator that something is wrong.
-Anish
--
Eric Johnson wrote:
> Hi Anish,
>
> Anish Karmarkar wrote:
>> Eric Johnson wrote:
>>> Hi Anish,
>>>
>>> Anish Karmarkar wrote:
>>>>> Since the message is already in text format the "encoding"
>>>>> attribute in the XML header must be ignored.
>>>> Perhaps not the best place to discuss this, but why is the encoding
>>>> attribute in the XML preamble ignored?
>>> Ah, perhaps we really do need similar text in our JMS binding
>>> specification, then? If this isn't immediately obvious, then perhaps it
>>> deserves restating. I'll raise an issue to that effect.
>>>
>>> The "encoding" header in the XML stream is there to tell you how to
>>> interpret a stream of *bytes*. By the time you're looking at a JMS
>>> TextMessage, you're already looking at *characters*.
>>>
>> This may be simple case of misunderstanding (on my part).
> Yes, definitely an misunderstanding on your part - at least I'm reading
> it that way.
>> I'm assuming that we are talking about the xml preamble attribute
>> 'encoding'. e.g. <?xml version="1.0" encoding="utf-8"?>
> Yes, perhaps useful to others to clarify that!
>> Since this is SOAP over JMS, the web services binding layer would use
>> the JMS apis to send/receive the SOAP infoset/xml. The SOAP
>> infoset/xml is transported over JMS as a text message.
> Well, that's just the problem. The SOAP/JMS binding specification lets
> you choose to use either TextMessage or BytesMessage - the same as we've
> chosen to do with the jms binding specification. So when you say "the
> SOAP infoset/xml is transported over JMS as a text message", that isn't
> true - it is transported either as bytes or characters depending on your
> choice of message type.
>
>> The web services layer either uses the SOAP infoset (which is abstract
>> and encoding attribute is not present) or deals with the serialized
>> XML. The encoding attribute comes into play only when dealing with
>> serialized XML.
> "serialized XML" is just a little too imprecise, in that you can
> serialize XML to a string of characters, and then using whatever
> encoding you wish, encode those characters as serialized bytes. The XML
> specification requires that the "encoding" in the preamble match the
> character set used to generate bytes. But if you never generate
> bytes..., you never need the encoding header.
>> If serialized xml is used (anywhere), one can't ignore the encoding
>> attribute. No?
> Yes, you can. If you only serialize to characters, rather than bytes,
> then the encoding is spurious, because it hasn't been applied yet.
>
> -Eric.
>> -Anish
>> --
>>
>>> -Eric.
>>>> -Anish
>>>> --
>>>>
>>>> Eric Johnson wrote:
>>>>> As per my action item from this last conference call, here's a link
>>>>> to the text which we just added around using TextMessage with JMS.
>>>>>
>>>>> http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/soapjms.html?content-type=text/html;%20charset=utf-8#textmessage-considerations
>>>>>
>>>>>
>>>>>
>>>>> Since this is a reference into a working document CVS, I'm pasting
>>>>> the text below as well:
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> 2.4.1 Considerations For Using TextMessage
>>>>>
>>>>> While the use of |TextMessage| may be attractive in some scenarios,
>>>>> there are some considerations that go along with it.
>>>>>
>>>>> *
>>>>>
>>>>> Since the message is already in text format the "encoding"
>>>>> attribute in the XML header must be ignored.
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail. Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php