Re: SVG12: image/svg+xml gzip requirements
* Thomas DeWeese wrote:
Please don't rewrite the TAG finding. The TAG indicates that User agents should 'notify' the user of the problem. It does not say that these documents must be rejected.
Appendix F.1 of the SVG 1.1 Recommendation requires that rendering must stop after a fatal error as defined in the XML 1.0 Recommendation has been encountered, which in case of the relevant documents means after reading the very first octet of the binary resource. The TAG finding, even if it disagrees with the SVG 1.1 Recommendation, has no authority to override this conformance requirement.
I might also point out 4.2 where the last paragraph says:
Representation providers SHOULD NOT in general specify the character encoding for XML data in protocol headers since the data is self-describing.
Which would seem to support not including the character encoding in the SVG mime type.
It does not. It says you should not use the charset parameter, it does not say XML MIME Type registrations should define inconsistent processing rules for XML resources that use the charset parameter. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Bjoern Hoehrmann wrote:
* Thomas DeWeese wrote:
Please don't rewrite the TAG finding. The TAG indicates that User agents should 'notify' the user of the problem. It does not say that these documents must be rejected.
Appendix F.1 of the SVG 1.1 Recommendation requires that rendering must stop after a fatal error as defined in the XML 1.0 Recommendation has been encountered, which in case of the relevant documents means after reading the very first octet of the binary resource. The TAG finding, even if it disagrees with the SVG 1.1 Recommendation, has no authority to override this conformance requirement.
But this is a case of inconsistent meta-data. The sender says that the data is not encoded, but the content indicates that it is GZIP encoded. Thus the user agent is allowed via the TAG to notice this inconsistency and override the sender metadata (the UA at this point should also notify the user of the override). Once it has overridden the sender data it can interpret the data stream as GZIP compressed and get a valid XML Document. I don't see a reason why any UA that accepts XML content might not follow this procedure, it is obviously more likely for SVG UA's since they are required to support GZip compressed content.
I might also point out 4.2 where the last paragraph says:
Representation providers SHOULD NOT in general specify the character encoding for XML data in protocol headers since the data is self-describing.
Which would seem to support not including the character encoding in the SVG mime type.
It does not. It says you should not use the charset parameter, it does not say XML MIME Type registrations should define inconsistent processing rules for XML resources that use the charset parameter.
Saying there can/should not be a charset parameter for image/svg+xml or if there is one it _must_ match the XML document's encoding is not the same as defining inconsistent processing rules, it is supporting the TAG finding. As I have stated before if senders conform to the mime-type registration no conflict can possibly occur, everyone processes the content consistently. If they don't follow the mime-type registration than the transfer is invalid (and my suggestion was to simply leave the results undefined). After all the sender has to "decide" to send "image/svg+xml" at the same time they should "decide" not to send a charset (or ensure it matches). What I don't get is why you think image/svg+xml can not possibly have anything different about it from text/xml. Does this mean that all the SVG UA's are in error because they process the document and display it as graphics? After all that isn't what existing XML processors do they must be broken... I think that as long as someone _following_ the image/svg+xml mime-type registration does not break existing XML processors there is no legacy problem. This would allow the registration to explicitly disallow charset and not break anything or require that it _always_ match with undefined behavior if it doesn't. If it specified the charset parameter was ignored that would be problematic. Does anyone think it really was a good idea to allow for a charset that differs from the content? Or are we just propagating a bad decision on future generations?
On Wednesday, December 8, 2004, 6:38:43 PM, Bjoern wrote:
I might also point out 4.2 where the last paragraph says:
Representation providers SHOULD NOT in general specify the character encoding for XML data in protocol headers since the data is self-describing.
Which would seem to support not including the character encoding in the SVG mime type.
Yes, exactly. BH> It does not. It does, too! :) You know, I was i a TAG meeting last week and checked with the other folks exactly what it says and what the intent is and, I have to say, it does, too. BH> It says you should not use the charset parameter, Right. It says don't use it. I have spent some considerable time discussing with Martin Dürst at the end of last week, and we identified a couple of cases (dumb transcoders that don't know any XML, and JSP generators) where its easier to generate a charset to fix up problems than it is to generate a correct xml encoding declaration. In all the resst of the cases, havin ga correct encoding declaration is far preferable. It then becomes a discussion of what is easier to fix a) improve the dumb transcoders (for example, if they don't know any XML then treat all +xml types as binary) and the dumb JSP, or b) make every implementation have to deal with a charset parameter that should not be used. BH> it BH> does not say XML MIME Type registrations should define inconsistent BH> processing rules for XML resources that use the charset parameter. No, it says that if present the charset parameter should give the same information as the xml encoding declaration. In other words, it recommends the well implemented, consistent and interoperable path (nontext/*+xml with no charset parameter and a correct encoding declaration ) rather than the vague and inconsistently implemented path (mutually inconsistent metadata with priority rules, and a requirement to rewrite instances when saving to disk or to upgrade all disk operating systems to store per-file MIME metadata). -- Chris Lilley mailto:chris@w3.org Chair, W3C SVG Working Group Member, W3C Technical Architecture Group
participants (3)
-
Bjoern Hoehrmann -
Chris Lilley -
Thomas DeWeese