Re: Rough sketch for an I-D (a successor of RFC 3023)

On Friday, October 31, 2003, 8:32:26 PM, François wrote:

FY> Chris Lilley a écrit  :
>> FY> Clients should be explicitly encouraged to fix the encoding declaration
>> FY> when saving locally.
>> Clients should never be served nonwell-formed documents that they need
>> to 'fix up'.

FY> According to the XML spec, a doc with a wrong encoding declaration, but
FY> accompanied by a correct charset from a higher-level protocol, is 
FY> well-formed.

I agree that it is temporarily well formed. However, its still not
well formed on the server.

FY>  It needs to be fixed up if saved locally.  IMHO clients
FY> SHOULD fix it and 3023bis should say so.

They should not need to, so another way to approach this is to say
that XML SHOULD NOT be served with an encoding declaration that
differs from the charset.

Then they don't need to do any 'fixing up' on the client.

Is there much implementation experience with this 'fixing up'?

FY> There are legitimate use cases for this.

Possibly, that is why I suggested SHOULD NOT rather than MUST NOT.

In general, if some software is taking in well formed XML and emitting
non-well-formed XML (for example, by transcoding it without also
altering the encoding declaration to suit) then it is that software
which is broken and needs to be fixed. Breaking everything else for
the sake of some dumb transcoding proxies that could very well detect
+xml in the media type and do the appropriate thing, is deeply broken.

FY> I don't think a nonwell-formed document sitting on a server is,

Glad you agree. I really do not want to see xml generators emitting
XML without an encoding declaration and assuming that a server will
somehow sniff the correct encoding, send this along as a header, and
then hope that the client will fix it up.

FY> but a doc transcoded on the fly is one.

The transcoder should take better care with its XML, then. Its will
also break any signed, canonical XML.


Received on Friday, 31 October 2003 17:41:05 UTC