[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp-wsia] Re: [change request #178] markupCharacterSet in MarkupContext
right, uploadContext is another candidate that should be handled equally.
I also agree to your second paragraph. The conformance statements talking
about using SOAP or not started my confusion and questions :-)
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 02/26/2003 12:53 |
| | PM |
|---------+---------------------------->
>--------------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Richard Jacob/Germany/IBM@IBMDE, wsrp-wsia@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsrp-wsia] Re: [change request #178] markupCharacterSet in M arkupContext |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Agree we need the RFC reference and an example. It may turn out that
attachments will also carry a mime type (with charset parameter) in a
similar way to markupBinary (also uploadContext containing text) and it
would be nice to have this formatted the same as the
markupContext.markuptype, if both are allowed to be provided.
What becomes really confusing is that we are making conformance statements
about different levels: SOAP messages and application types. We should keep
the rules for markupString simple (likely to be utf-8 or utf-16 for SOAP
and
always 2 byte chars for application) but allow markupBinary and attachments
to be used if the markup needs to be in a specific charset (and let a mime
processor take the strain).
regards,
Andre
-----Original Message-----
From: Richard Jacob [mailto:richard.jacob@de.ibm.com]
Sent: 26 February 2003 10:54
To: wsrp-wsia@lists.oasis-open.org
Subject: RE: [wsrp-wsia] Re: [change request #178] markupCharacterSet in
M arkupContext
Andre, I agree we can use the definiton found in RFC1521 and RFC1522 (I
think RFC1521 defines the "charset" parameter - so referring to RFC1521
would be appropriate).
But at least we must state the syntax used in the spec (by refering to
RFC1521 and by example).
I also agree that this would be for markupBinary.
I was a little bit confused by the fact that we are stating that the
charSet must be the same as of the response message in case of the SOAP
binding when using markupString. As we are a webservice our messages are
always XML, right? Then the charSet of markupString is _always_ the same
as the XML charSet returned independant of the binding, or am I missing
something here?
My question is if there are reasons for having the original char set if
using markupString?
In this case we could add that the markupType SHOULD include the charset
parameter if returning markupString? I'm not sure about that.
I'm not sure if I understand you second paragraph.
If you are using a (java, for example) web stack what you get back is a
string (2 bytes chars in java) and don't care about the char set on the
wire.
But if you process the XML messages on your own, you want to know the char
set.
Mit freundlichen Gruessen / best regards,
Richard Jacob
______________________________________________________
IBM Lab Boeblingen, Germany
Dept.8288, WebSphere Portal Server Development
Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
Email: mailto:richard.jacob@de.ibm.com
|---------+---------------------------->
| | Andre Kramer |
| | <andre.kramer@eu.|
| | citrix.com> |
| | |
| | 02/25/2003 06:10 |
| | PM |
|---------+---------------------------->
>
---------------------------------------------------------------------------
-----------------------------------------------------------------------|
|
|
| To: wsrp-wsia@lists.oasis-open.org
|
| cc:
|
| Subject: RE: [wsrp-wsia] Re: [change request #178]
markupCharacterSet in M arkupContext
|
>
---------------------------------------------------------------------------
-----------------------------------------------------------------------|
I assumed the syntax was specified by the MIME RFCs
(http://www.faqs.org/rfcs/rfc1522.html), e.g. : "; charset=utf-8". This
should only be a concern if we use base64 or attachments to send string
data.
For markupSting (sending a string as a string), I do not see why we need to
determine the charset of the used at the transport level. The application
should get a 2 byte char string (independent of whether or not SOAP was
used)?
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 25 February 2003 16:04
To: wsrp-wsia@lists.oasis-open.org
Subject: [wsrp-wsia] Re: [change request #178] markupCharacterSet in
MarkupContext
Document: Spec
Section: 6.1.10
Page/Line: 31/26
Requested by: Richard Jacob
Old text: none
New text: [o] string markupCharacterSet
Reasoning:
Add information what charSet the returned markup actually is. This field
then must appear on the wire if markupString/Binary is returned.
Currently we state that if markupBinary is returned, the MIME type must
include the char set. But we don't define the syntax at all. If we don't
add markupCharacterSet we need to define the syntax here.
Second, if we return markupString and use anything other than soap, then
the charset must match one of the requested or be UTF-8, but which one?
The Consumer can only guess here.
[RT] Even when SOAP is used, most stacks will map the string into UTF-8
and this will be seamless for many charsets. If the Consumer is using some
other charset for the aggregated page, how complex is it to process this
charset conversion without information about the original charset?
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC