- From: <bugzilla@jessica.w3.org>
- Date: Mon, 22 Sep 2014 16:36:34 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26784
C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
The following remarks reflect the tentative views of the editors of the
serialization spec, after some discussion.
On 1 (duplicate map keys), we note that RFC 7159 does not impose a
uniqueness constraint on member names in an object, although it notes
that some JSON parsers will raise an error on them. The WG seems to
face a choice here:
(A) Make no substantive change, on the grounds that RFC 7159 does
not make duplicate object-member names an error.
Optionally, add a note to warn users that if they care about
avoiding duplicate object names, they need to take steps to
ensure that they are not omitted.
(B) raise an error, on the grounds that object member names are
normally supposed to be unique in JSON, RFC 7159 explicitly
warns of interoperability issues with them, and many users will
want a serialization error rather than an error in the next JSON
ingest step.
Optionally, add a serialization option to specify that duplicate
object-member names should not raise an error. (We'd be happy
to let try/catch handle this, but try/catch doesn't seem to work
for implicit serialization.)
On 2 (implementation-dependent order of map keys): agreed. Good
catch.
On 3 (atomization vs serialization). The WG will need to decide this.
If we understand correctly, the differences between the current draft
and the proposal to use serialization rather than atomization can be
illustrated with the following sample map:
map {
"able" := <e>42</e>,
"baker" := <f>1 2 3 4 5</f>,
"charlie" := <f><e>1</e><e>2</e><e>3</e><e>4</e><e>5</e></f>,
"dog" := <p>The design goals for XML are:
<list type="ordered">
<item>
<p>XML shall be straightforwardly usable over
the Internet.</p>
</item>
...
</list>
</p>
}
Under the current draft (augmented with the rules suggested below to
serialize non-empty sequences as JSON arrays and escape JSON strings
as needed), if all the elements are untyped, this would (I think)
produce
{ "able" : 42,
"baker" : [1, 2, 3, 4, 5],
"charlie" : "12345",
"dog" := "The design goals for XML are:\n\t\n\t\t\n\t\t\t\nXML ..."
}
If the 'f' element is typed as an element-only element, then the
"charlie" member would produce an error when atomization attempted to
access the typed value of the 'f' element.
If we perform serialization rather than atomization, the results
should be more like this (is this a correct understanding of the
intention?):
{
"able" : "<e>42</e>",
"baker" := "<f>1 2 3 4 5</f>",
"charlie" := "<f><e>1</e><e>2</e><e>3</e><e>4</e><e>5</e></f>",
"dog" := "<p>The design goals for XML are:\n\t<list
type=\"ordered\">\n\t\t<item>\n\t\t\t<p>XML ..."
}
On the one hand: atomization serializes more elements as data values,
which seems likely to be often what JSON users desire. And on the
other: serialization serializes more elements without errors, which
also seems likely to be a desired property.
On 4 and 5 (indentation): agreed.
On 6 (character escaping): agreed.
On 7 (item-separator): we propose to specify that item-separator is
not relevant to JSON output.
On 8 (serialize non-empty non-singleton sequences as arrays): agreed.
On 9 (INF, NaN, function items, ...): agreed.
We hope to have draft wording reflecting these changes for the WG to
review tomorrow.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Monday, 22 September 2014 16:36:39 UTC