- From: Chris Lilley <chris@w3.org>
- Date: Mon, 1 Nov 2004 20:03:17 +0100
- To: Bjoern Hoehrmann <derhoermi@gmx.net>
- Cc: www-svg@w3.org, ietf-types@iana.org
On Monday, November 1, 2004, 2:49:32 AM, Bjoern wrote: BH> Dear Scalable Vector Graphics Working Group, BH> http://www.w3.org/TR/2004/WD-SVG12-20041027/mimereg.html attempts to BH> register the "image/svg+xml" MIME Type but the registration lacks the BH> charset parameter as defined in RFC 3023. This defeats the purpose of BH> the +xml convention which attempts to provide a means for generic XML BH> processing. On the contrary! The +xml convention clearly indicates, for an unknown media type, that it is xml; thus, that an XML processor should be used; which will correctly determine the encoding from the xml encoding declaration or lack therof. I was able to discuss this with Murata-san in Tokyo at SVG Open, and he agreed that the +xml convention, plus the deprecation of text/xml and associated charset handling weirdness of required us-ascii fallback, allows consistent handling BH> Generic XML tools such as Validators, Editors, XSLT and XQuery BH> processors, and full-text XML search engines would need to maintain BH> special knowledge to ignore the charset parameter for image/svg+xml BH> documents No, they would not. RFC 3023 already allows the charset to be omitted, and gives rules to follow for this case. SVG follows those rules, as the registration document makes plain. However, if such a parameter were to be added, anything that downloaded an SVG document (or any other type of document that used a charset parameter) would have to know to change the encoding declaration in the xml - otherwise it would be on well formed when read from local disk. this is expensive and unlikely to happen. BH> which is expensive and unlikely to happen. In fact, a number BH> of deployed tools already don't do that, for example the W3C Markup BH> Validator would need to be updated with special code for image/svg+xml BH> in order to comply with the registration. Incorrect; see above. BH> Thus, please change the registration to be consistent with application/ BH> xml as defined in RFC 3023. In fact it is consistent already, but refers to specific cases while excluding other cases. Speaking as one of the co-editors of the revision to RFC 3023, which removes this requirement and deprecates text/xml, thus bringing it into line with the good practice notes in the AWWW document: http://www.w3.org/TR/2004/WD-webarch-20040816/Overview.html#xml-media-types Good practice: XML and "text/*" In general, a representation provider SHOULD NOT assign Internet media types beginning with "text/" to XML representations 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 I can confirm that the idea is to apply this more generally. In other words, the omission of the charset parameter was not an oversight; it was a deliberate design choice following discussions in the TAG over the last year and a half. -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
Received on Monday, 1 November 2004 19:03:18 UTC