Re: SVG12: image/svg+xml gzip requirements

Thomas DeWeese wrote:
>    I don't think there is generally any other way to detect
> inconsistent meta-data is there?

Sure there is, when there are actually two sets of metadata.  You just compare them.

> Heck even within XML the detect of UTF-8/16 relies on this basic technique.

This is only needed in XML because the metadata cannot be read without this 
indication, basically.  And that's a consequence of not having a place to store 
metadata outside of the main data in typical filesystems...

But we're dealing with the Web, and there _is_ a place to store metadata outside 
of the data itself there.

>> This all sounds to me like an attempt to legislate existing broken UA 
>> and content provider behavior into technically being correct.... 
> 
>    Who said any of this was a matter of "correct".

We're talking about what sort of behavior is considered conformant (equivalent 
to being correct, in my mind, when talking about specifications) to the SVG 
specification.

> Clearly the transfer has problems

That's not at all clear to me, actually....

> you stated that taking the simplest of steps
> (as suggested by the SVG specification) to figure out what the problem
> was is inconsistent with the TAG finding.

Where did I ever mention TAG?  Please cite such claims.

My only claim was that in the face of data delivered with a certain MIME type 
and certain Content/Transfer-Encoding, it seems inappropriate to ignore either 
the type or the encoding based on sniffing the data.  I frankly don't care 
whether that's consistent with the TAG specification all that much.

Note that lack of an encoding header falls under this claim, since it's 
explicitly listing the "identity" encoding (there is no other way to indicate 
this encoding per the HTTP specification).

-Boris

Received on Wednesday, 8 December 2004 20:09:36 UTC