[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Heed this warning about Postel's Prescription

• From: Rick Jelliffe <rjelliffe@allette.com.au>
• To: "Roger L. Costello" <costello@mitre.org>
• Date: Tue, 30 Jun 2015 11:41:07 +1000

Nonono! 

The BOM way 1. is allowed by XML and arose because of a gap in the Unicode specifications, and therefor an early ambiguity inherited by XML.

But way 2 completely goes against XML draconian error WF rules, and is the kind of muddle-headed hacking that has made i18n too difficult for most developers to understand or ever get right, with systems acting differently. Developers are, in general, fantastically willing to come up with the wrong theory about what is causing an encoding error, only matched by their determination to avoid looking at the actual byte codes directly, using a hex editor. The most common cause of 'decoding errors' is that the XML is being read using  an encoding that does not match the actual encoding of the resource [ie the XML header was generated wrong at write time, and/or is not being used at read time] : allowing silent 'resynchronizing' corrupts the data, delays problem detection, and allows the developer to defraud their bosses by claiming to have implemented XML when all they have done is disable error detection.

Rick

• References:
  • Heed this warning about Postel's Prescription
    • From: "Costello, Roger L." <costello@mitre.org>
  • Re: Heed this warning about Postel's Prescription
    • From: Rick Jelliffe <rjelliffe@allette.com.au>
  • RE: Heed this warning about Postel's Prescription
    • From: "Costello, Roger L." <costello@mitre.org>