Re: SVG12: charset parameter for image/svg+xml

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