W3C home > Mailing lists > Public > www-forms-editor@w3.org > June 2008

encoding, charset, and SOAP

From: Paul Butcher <paul.butcher@webbackplane.com>
Date: Thu, 12 Jun 2008 16:34:58 +0200
To: www-forms-editor@w3.org
Cc: public-forms@w3.org
Message-ID: <5d62ecc70806110844l4e5e55e9mb4ad48467815722f@mail.gmail.com>

On: http://lists.w3.org/Archives/Public/www-forms/2007Mar/0060.html

There is nothing in the spec that explicitly states what @encoding should
do,   it is defined as

"Optional attribute specifying an encoding for serialization. The default  

I interpret this as meaning that the character set of the data being
serialised is defined by @encoding, and that is all, there is no  
to inform the server of that fact.

A processor that sends the value of @encoding along with the submitted data
is doing some added-value, rather than conformant behaviour.

For Soap, "If the submission mediatype contains a charset MIME parameter,
then it is appended to the application/soap+xml MIME type"

The existence of specified behaviour for SOAP, alongside the absence of
specification regarding @encoding, suggests that mediatype charsets must

So, there are two reasonable options:
a) continue to append @encoding as charset, but check first, to see if
charset already exists.
b) stop appending @encoding as charset altogether.

I think a) is preferable.

Either of these raise the issue that conflict between @encoding, and a
mediatype charset could occur, so a third option is possible:

c) append @encoding as charset, if mediatype and @encoding specify  
charsets, ignore mediatype.

However, since @encoding has a default value, pretty much translates as
ignore any charset defined by mediatype, as, if it is wrong, it will be
discarded, and if it is right, it will already be there.

Then again, if form authors really want to do something like send a UTF-8
document but tell the server that it is UTF-16 should implementers or spec
authors really care?

So, I believe that a) is still the preferable option.


Received on Thursday, 12 June 2008 14:37:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:12 UTC