Re: SVG 1.2 Comment: image/svg+xml;charset=""

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