Martin J. Dürst writes: > Hello Henry, others, > > The fact that some libraries or Web sites accept a BOM for JSON isn't > a proof that all (well, let's say the majority) accept a BOM. I wasn't suggesting that it did, rather that the kind of testing that needed to be done was testing that included the interface between transport and parser, not parser alone, since, as we are all agreed, the BOM is not allowed by the language itself. >> As previously discussed, _no-one_ is arguing that BOMs are in the JSON >> language as such. JSON parsers shouldn't accept BOMs. >> >> BOMs are, to quote the UNICODE spec, "not part of the text". It is >> appropriate that specs concerned with JSON-on-the-wire, for example >> the media type registration for 'application/json', _should_ discuss >> the BOM, and it's open to them, _without changing the language at >> all_, to say that BOMs are acceptable but, again, are not part of the >> text which the parser has to accept. > > I agree that *from a theoretical viewpoint*, this is correct. But > theory isn't everything. As I have written before (and you have cited > in another thread, for another spec): > > What's most important now is to know what receivers actually > accept. We are not in a design phase, we are just updating the > definition ... and making sure we fix problems if there are > problems, but we have to use the installed base for the main > guidance > > For our update from RFC 4627, the null hypothesis is that there are no > BOMs (neither for UTF-8 nor for UTF-16). The patterns given in > http://tools.ietf.org/html/rfc4627#section-3 cannot apply to > characters, they can only apply to bytes. If we want to allow a spec > in application/json, then we have to have strong evidence that almost > all parsers can deal with BOMs, not just fragmentary evidence that > some parsers don't choke on a BOM. I'm not suggesting parsers should allow BOMs, if by parser you mean what implements the grammar of the language. And I'm certainly not suggesting that two examples pulled at random from a Google search constitute strong evidence about practice at large. All I was trying to suggest was that showing that the language parser as such in Firefox etc.didn't allow BOMs, as the OP had done, was the right kind of evidence _either_. > Please note that there's some parallel to XML, in that neither Unicode > (for the encoding form) nor the IETF (for the 'charset') require a BOM > for "UTF-16", but XML nevertheless strictly requires it. I agree that XML is a useful point of comparison, in particular because it too does not allow a BOM as part of an XML document, but rather treats it as an aspect of packaging/transport external to the XML document, which seems to me to be the kind of approach to BOMs the JSON WG might consider. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@xxxxxxxxxxxx URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam]