We're probably looking at the problem from two different angles. I would
recommend using the right encoding at the HTTP level (i.e. via a
content-type parameter) so that any party along the way (including the
client) can accurately represent the content without parsing it.
Subbu
On 2/11/07, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
Subbu Allamaraju wrote:
> On 2/11/07, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
>>> header("Content-Type: application/xhtml+xml; charset=UTF-8");
>>
>> You don't need to include the charset parameter in this header for
>> XML MIME types (this does not apply to text/html). XML is designed
>> as a self describing format and does not need the information to be
>> there.
>
> Will you care to elaborate this? You're saying that since "xml is
> self-describig" there is no need to include the encoding parameter in
> content-type.
Yes.
http://www.w3.org/TR/2004/REC-webarch-20041215/#xml-media-types
> In the absence of the encoding parameter in the content type, the client
has to parse
> the preamble using some default/safe encoding, and then reparse the
> complete response with the encoding found in the preamble. The
> encoding parameter in the content type saves this trouble.
While that is true under some conditions for HTML when you declare the
encoding using the meta element instead of at the protocol level, it is
not true for XML. An XML parser never needs to reparse anything.
The algorithm in the XML recommendation has been carefully designed to
ensure that the encoding can always be reliably determined, or else it
is a fatal error. See Appendix F.
http://www.w3.org/TR/REC-xml/#sec-guessing
--
Lachlan Hunt
http://lachy.id.au/
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
--
------------------------------
http://www.subbu.org
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
*******************************************************************
