- From: Chris Lilley <chris@w3.org>
- Date: Tue, 23 Nov 2004 17:22:05 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: Robin Berjon <robin.berjon@expway.fr>, www-svg@w3.org
On Tuesday, November 23, 2004, 4:36:57 PM, Bjoern wrote: BH> * Robin Berjon wrote: >>If you disagree, take it to the TAG because we're sure sticking to their >>recommendation: >> >> http://www.w3.org/TR/webarch/Overview.html#xml-media-types BH> <http://www.imc.org/ietf-xml-mime/mail-archive/msg00984.html>: BH> [...] BH> I do not see any way to justify removing the 'charset' parameter BH> based on 'good practice' advice in the Web Architecture document BH> [...] Well, http://www.w3.org/TR/webarch/#no-charset seems a pretty clear good practice note. Good practice: XML and character encodings In general, a representation provider SHOULD NOT specify the character encoding for XML data in protocol headers since the data is self-describing. And also the approved TAG finding http://www.w3.org/2001/tag/2002/0129-mime#char-encoding See also http://lists.w3.org/Archives/Public/www-tag/2004Oct/0016.html clearly points out the problem with what RFC3023 currently says. "Thus there is no ambiguity when the charset is omitted, and the STRONGLY RECOMMENDED injunction to use the charset is misplaced for application/xml and for non-text "+xml" types. Consequently, for XML representations, server-side applications SHOULD only supply a charset header when there is complete certainty as to the encoding in use. Otherwise, an error will cause a perfectly usable representation to be rejected by an architecturally sound client. "We recommend that section 7.1 of [RFC3023] be amended to something like the following: " The use of the charset parameter, when the charset is reliably known and agrees with the encoding declaration, is RECOMMENDED, since this information can be used by non-XML processors to determine authoritatively the charset of the XML MIME entity." Note also that, if a) the xml encoding declaration and the charset parameter are required to agree b) the charset is only used by non-xml processors c) there is not the requirement to prent the content as text (as there is in text/* types) d) the usual response for a non-recognised type is to save it to disk then what circumstance exactly would ever use this functionality. I can't think of a single example of a non-xml processor that could do anything meaningful here. What exactly is the use case? >>Well a new ship's up with the updated RFC 3023 that deals with all the >>previous bugs. BH> SVG processors and general purpose XML processors need to determine the BH> same character encoding for image/svg+xml;charset=... resources, The point is that there should be no such content. BH> nothing BH> in RFC3023 or the current RFC3023bis ensures that if the SVG 1.2 spec BH> requires implementations to ignore the charset parameter. Its not 'ignore'; its 'not present'. BH> You might well BH> argue that RFC3023bis should either require implementations to ignore BH> the charset parameter for all types or that implementations reject BH> documents when honoring the charset parameter yields in different BH> resules than when ignoring it, Actually, the second one (that it should be an error for the two items of metadata to differ) is currently under discussion. http://lists.w3.org/Archives/Public/www-tag/2004Nov/0027.html >>And the best way to achieve that is to not use charset parameters. BH> Using the parameter and specifying processing when it is used are quite BH> different matters. Yes, certainly. BH> I for example could live with registration text in BH> SVG 1.2 that has a charset parameter but states that using it is BH> STRONGLY DISCOURAGED or something. strongly discouraged means that everyone has to support it, but it is not actually used. I am tired of such things in specs - if something has no use then don't add it, rather than adding it and propagating a secret knowledge that in practice no-one does that.... So I would far rather go for not having it - its cleaner, more interoperable, eases implementation, and fits with the Web Architecture better. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Tuesday, 23 November 2004 16:22:06 UTC