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(_at_)inf(_dot_)ed(_dot_)ac(_dot_)uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail from me _always_ has a .sig like this -- mail without it is forged spam]