SVG12: image/svg+xml gzip requirements

[Chris Lilley]

On Wednesday, December 8, 2004, 10:39:53 PM, Bjoern wrote:

BH> * Thomas DeWeese wrote:
>>>>   Huh?  If the network layer detects that the HTTP response
>>>>is in fact GZip encoded even though the header isn't set and decodes
>>>>it why is this a problem?
>>> 
>>> Because such software does not interoperate with software that does not
>>> perform such error correction. 
>>
>>    Well, you are free to your option but don't reference a TAG finding
>>saying it doesn't support this behavior when it clearly does!

BH> <http://www.w3.org/2001/tag/doc/mime-respect.html>:

BH> [...]
BH>   Format specifications SHOULD NOT work against the Web architecture
BH>   by requiring or suggesting that a recipient override sender-provided
BH>   metadata without user consent.
BH> [...]

And thus, a charset which conflicts with the instance, although
authoritative, is a source of problems. Which is why we say not to
provide one, unless its known to not conflict, and even then, no really
good reason to.


BH> Use of the +xml convention implies that such metadata needs to be
BH> overridden

No, it does not. An xml encoding declaration is sender provided
metadata. However, in the case where a charset parameter is allowed, and
where it can be different, and thus where one has to win over the other,
metadata is indeed being overridden. I agree with you that silent
recovery here is not inthe user interest and a warning should be shown.

BH> (e.g. by implying further metadata) in order to process the
BH> content any further than the first character. You will find further
BH> information in the TAG finding that supports my claim, for example, the
BH> HTML sniffing in section 2.1 is not much different from gzip compression
BH> sniffing. You will also find that the AWWW document goes even further
BH> and constraints "Agents MUST NOT ignore message metadata without the
BH> consent of the user" and includes the principle "Agents that recover
BH> from error by making a choice without the user's consent are not acting
BH> on the user's behalf". The proposed registration does not discuss user
BH> consent in any way and is thus inconsistent with the requirement in the
BH> TAG finding, and actually with the "Architecture of the World Wide Web",
BH> too.

Actually, its specicially written to be very consistent with it, by not
allowing a source of conflict and thus never getting into the situation
where conflicting metadata needs to be handled. So, the user does not
need to assent to anything. Simple, really.

BH> If the registration is changed to require user consent to this operation
BH> it might be more consistent with these TAG findings;


No, it would just conflict with the parts you already quoted and with
other parts you didn't.

BH>  I would not accept
BH> such a resolution though.

Great.

BH> I very much disagree that the TAG supports
BH> silent error recovery.

It doesn't.

BH>  If you think my interpretation of these TAG
BH> publications is not what the TAG really intended,

That would be a 'yes'

BH> please request that
BH> the TAG clarifies their materials so we can discuss this on more solid
BH> grounds.

The materials are clear, but you seem determined to go for the less
interoperable path and to bend the TAG materials through 180 degrees,
for reasons that I find hard to understand.




-- 
 Chris Lilley                    mailto:chris at w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group