Re: MIME Type Review Request: image/svg+xml

On Wednesday, November 24, 2004, 3:18:50 PM, Bjoern wrote:


BH> * Chris Lilley wrote:
>>BH> Your proposals so far render all applications for which RFC3023 would
>>BH> be relevant non-compliant regardless of whether they implement only
>>BH> some part of RFC3023, the entire specification or implement it not at
>>BH> all.
>>
>>That is incorrect. You seem to miss that once RFC3023 is updated to
>>ensure that the encoding and the charset are the same, the *sole* use of
>>a charset parameter is for non-xml applications.

BH> The use of the charset parameter so far does not seem actually relevant
BH> to this discussion. If I understand correctly that you propose to make

BH>   Content-Type: application/xml;charset=iso-8859-1

BH>   <?xml version="1.0" encoding="utf-8"?>
BH>   ... iso-8859-1 content ...

BH> non-conforming,

As you yourself pointed out, per RFC3023

   Processors generating XML MIME entities MUST NOT label conflicting
   charset information between the MIME Content-Type and the XML
   declaration.

such content is already non conforming.

BH> I would expect that your proposal includes a requirement for
BH> implementations to detect this error and probably also a requirement
BH> to reject such resources.

Since its already non conforming, we just have to deal with the
non-conforming situation. My solution further discourages such content
and is consistent with the architectural principle that silent recovery
from error is harmful

http://www.w3.org/TR/webarch/#no-silent-recovery

In terms of dealing with such content if it still occurs, the XML well
formedness rules already handle that in an entirely satisfactory manner
and nothing further need be added. These are already well implemented
and highly interoperable.

BH> Both requirements would render implementations
BH> of RFC3023 non-conforming since none of them do this.

Thats right, they don't raise an error. They either silently recover by
considering the charset authoritative or they silently recover by
considering the encoding declaration authoritative. Both
interpretations are observed in running code. In addition, when saving
to disk some (a few) alter the inconsistent xml encoding declaration to
make it correct, others (most) do not, thus depositing a non-well-formed
instance in local storage. And you are ok with that messy,
non-interoperable state of affairs?

>>And thus, what use is the redundant declaration? Note that currently
>>there is great variability in what processors do when reading and saving
>>content that has conflicting declarations. Removing the source of the
>>conflict brings us onto safer ground to the area where all
>>implementations behave the same. Surely you can see that this is good
>>and results in more robust, interoperable behavior?

BH> What do you consider the source of the conflict here? As far as I can
BH> tell that would be the charset parameter and as long as implementations
BH> are required to consider it to detect the character encoding the source
BH> of conflict is not removed.

This is doubtless why RFC 3023 says that people should not generate
content that has this conflict, and why TAG says the same thing, not to
generate it unless it is known to be correct. However, implementation
experience since RFC 3023 was issues shows that people do it anyway, and
its a significant problem; so it needs to be fixed. Pretending there is
no problem does not help the situation in any way.


BH> Maybe your point is that people will stop
BH> using the charset parameter in a way that creates potential problems if
BH> RFC3023bis has some conformance rules they make that seem reasonable to
BH> expect?

Right. That would include discouraging the use of an optional and
inconsistently implemented charset parameter for new registrations.

Existing registrations that use it we can do nothing about, although I
would like to see more testing of what processors do in the case of
inconsistent, non-conforming content.

BH> Maybe you can draft an improved proposal to change RFC3023 and post it
BH> to the relevant lists? That would certainly help the discussion.

Excellent suggestion, I will do exactly that (which is, of course, why I
took the action from the TAG to become co-editor. Its much more
effective for the TAG to say something is wrong, and help fix it, than
merely to say it is wrong).


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

Received on Wednesday, 24 November 2004 17:27:23 UTC