This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
A point was made during discussion of bug 26784 which ought to be captured and reviewed. It was pointed out (I forget by whom) that the rule that a sequence of length 2 or more is serialized as a JSON array prevents streaming: if items in the sequence are presented incrementally to the serializer, then it has to buffer item 1 in memory (which might be arbitrarily large) so that it can prepend a "[" in the case where a second item follows. We should consider the alternative, of disallowing a sequence of length >1. A more elaborate solution would be to handle a sequence of atomic values according to the current rule (buffering a single atomic value is no problem), but disallow sequences of length >1 if the first item is an array or map.
I don't think we should insert the equivalent of an XDM node as the result of serialization - a sequence is not an array, and we should not automatically convert a sequence to an array. If you want an array when you serialize, serialize an array.
The joint meeting today considered this report. We considered several alternatives including - raising an error when the sequence to be serialized (hereafter $s) has count($s) > 1 - serializing $s[1] when count($s) > 1 - raising a recoverable error when count($s) > 1 (with the expectation that serializing $s[1] would be the prescribed recovery path) - raising an error when count($s) > 1 and $s[1] is non-atomic, but otherwise behaving as described in the status quo document - adding a serialization parameter to control behavior - suggesting that the perceived conflict with streamability be handled in specs which define streamability (i.e. not in the serialization spec) There was strong preference, though not unanimity, in favor of the first of these: A sequence of length greater than one in the data model instance is a serialization error. Some points may be worth noting in passing: - Some WG members were motivated not by a concern for streamability but by an aversion to serializing sequences in the same way as arrays, which they took to be a violation of the principle of round-trippability. (Others argued that sequences are not currently round-trippable in any case, no matter how this bug is resolved. Neither party seemed to make any headway with the other.) - The conformance section of the serialization spec appears to make it possible for host languages to specify that a given serialization error is recoverable, even if the serialization spec does not so describe it, and similarly to specify that an error described as recoverable in the serialization spec must be raised, and not recovered from, in implementations of the host language. (So that the use of the term 'recoverable' in the serialization spec appears to have essentially advisory character.) The net effect is to endorse the proposal in the final paragraph of the problem description, "of disallowing a sequence of length >1". Michael Kay, as the originator of the bug report, will you please review this resolution and signal your assent to it, or dissent from it, in the usual way by closing or reopening this issue? Thank you. If nothing happens before the end of the last call period, the WGs will assume assent.