W3C home > Mailing lists > Public > public-soap-jms@w3.org > June 2008

Re: [SOAP-JMS] content questions - encodings question

From: Phil Adams <phil_adams@us.ibm.com>
Date: Tue, 24 Jun 2008 14:21:07 -0500
To: Eric Johnson <eric@tibco.com>
Cc: public-soap-jms@w3.org
Message-ID: <OFB3C870AA.C17DCD84-ON86257472.006A1F70-86257472.006A4DB9@us.ibm.com>
Hi Eric,
I should have gone back and read that section before commenting :)

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX
email: phil_adams@us.ibm.com
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599

Eric Johnson <eric@tibco.com>
Phil Adams/Austin/IBM@IBMUS
06/24/2008 02:09 PM
Re: [SOAP-JMS] content questions - encodings question

Phil Adams wrote: 

Hi Roland, 
For your first question below, I would like to suggest that instead of 
mentioning anything about specific media types that need to be supported, 
 we simply defer to the SOAP 1.1 and SOAP 1.2 specs.
I think you're referring to the bullet point below about section 2.2.3?  
If so, this point was not about media types, but about XML support, I 
believe.  See the comment from Peter's original markup:

Peter is apparently a sharp reviewer.  As it turns out, according to 
http://www.w3.org/TR/2006/REC-xml-20060816/#charencoding, conforming XML 
processors are only required to support UTF-8 & UTF-16, a detail which, if 
I once knew, I'd since forgotten.

My take - I don't think we have any reason to impose any additional 
constraints beyond base XML well-formed processing conformance.

  For a particular version of SOAP (1.1 or 1.2), the "SOAPJMS_contentType" 
property on the JMS message should behave exactly the same as the HTTP 
counterpart (i.e. the Content-Type HTTP header), IMO.    I would think 
that most vendor runtimes would use common code that processes the payload 
of the transport message (HTTP, JMS, etc.) together with the content-type 
value, without regard for which transport the message arrived on.   And 
for us to start to specify particular media types, etc. would just open 
the door for the SOAP/JMS spec to become out of sync with the SOAP/HTTP 
binding spec. 

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX
email: phil_adams@us.ibm.com
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599

Roland Merrick <roland_merrick@uk.ibm.com> 
06/24/2008 12:27 PM 
[SOAP-JMS] content questions

Greetings, during todays call we failed to get through all the "Content 
questions" [1] raised by Peter and Eric. The follwing still need some 
Section 2.2.3: contentType - Do we need to add statements requiring 
minimal support for various flavors of XML, or require that vendors 
support specific encodings? 
Section 2.2.3: We define a "requestIRI" property.  Do we want to change 
this to a requestURI property, but allow users to put an IRI in the 
contents? This will have a cascade effect in other places.... 

Interesting question, where do we actually allow IRIs and when are they 
converted to URIs. 
Section 2.2.4: Definition of fault codes with "IRI" in the name - do we 
want to change them to use URI? 

I would certainly say YES, change to URI. I certainly hope this is the 
case as Bhakti already changed to URI as part of the "universal" 
Section 2.7.2: If this is untestable, should we be specifying it? 


Regards, Roland

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 
Received on Tuesday, 24 June 2008 19:21:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:19 UTC