- 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 From: Eric Johnson <eric@tibco.com> To: Phil Adams/Austin/IBM@IBMUS Cc: public-soap-jms@w3.org Date: 06/24/2008 02:09 PM Subject: 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: http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/att-0007/soapjms.html#binding-message-props 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. -Eric. 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 From: Roland Merrick <roland_merrick@uk.ibm.com> To: public-soap-jms@w3.org Date: 06/24/2008 12:27 PM Subject: [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 resolution: 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" switchover. Section 2.7.2: If this is untestable, should we be specifying it? [1] http://lists.w3.org/Archives/Public/public-soap-jms/2008Jun/att-0015/00-part Regards, Roland Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Received on Tuesday, 24 June 2008 19:21:52 UTC