Re: SVG12: image/svg+xml gzip requirements

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?

Received on Wednesday, 8 December 2004 18:18:55 UTC