- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 Oct 2014 00:25:03 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27107 --- Comment #2 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> --- 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 28 October 2014 00:25:05 UTC