This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The "switch" construct first appearing in 2.4 UTF-8 is not previously introduced, e.g., in 1.7.2 Typographic Conventions. For clarity, it should be described before being used, as it is not obvious from a linear reading how to interpret the information in 2.4. Regards, Glenn
What are the various ways of interpreting the requirements in the UTF-8 decoding section? I don't understand how it could be interpreted other than the way it was intended.
I am pointing out that the use of the "switch construct" in 2.4 is the first time it is used in the spec, and that its structure is not explained prior to this fact. For example, you should explain the meaning of the bullet character (curved arrow) and how, in general, to interpret the stylistic convention employed in this construct (and elsewhere in the spec). (In reply to comment #1) > What are the various ways of interpreting the requirements in the UTF-8 > decoding section? I don't understand how it could be interpreted other than the > way it was intended.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: I don't really understand what that would mean. It's not really meant to be interpreted any particular way, it's just supposed to be modestly decorative. Each time the "switch" construct is used, it is explicitly explained (unless I've missed a case). If you disagree, it would help to see what kind of explanation you think would actually improve the readability of the spec.
Ian, really, this only needs a simple fix. Notwithstanding your comment below that "it is explicitly explained", in fact, the first time you use it in the document (in section 2.4 "UTF-8") you don't explain it. You need an explanation like: <quote> The following rules employ a typographic convention that notionally maps to a switch statement. Each bullet (↪) expresses a condition, followed optionally by other conditions, and finally a consequence (result) after a sequence of conditions. If some condition is satisfied, then the consequence obtains, then the switch terminates (i.e., the consequence includes an implied 'break'). Conditions are processed from the first to the last, until one holds or none is satisfied. </quote> My original comment was that you might want to include a generic description like this in the typographic conventions section 1.7.2. Regards, Glenn
I don't understand what this would add. Can you point me to a part of the spec that is not well-defined due to the absence of something like what you propose? Something where without the text you propose, there are multiple valid interpretations?
One thing it would add is me closing this bug report instead of keeping it open... which i will continue to do until satisfied... As for multiple interpretations, it is obvious to the most naive reader that both consequents may apply simultaneously, e.g., both of the following may be true: * One byte in the range FE to FF -> The whole sequence must be replaced by a single U+FFFD REPLACEMENT CHARACTER. * One byte in the range 80 to BF not preceded by a byte in the range 80 to FD -> Each byte must be replaced with a U+FFFD REPLACEMENT CHARACTER. In this case, which of the two consequents apply? You may say the first? Why is that? Why not the second? Since you have not bothered to explain this syntax, either interpretation is valid. Please do your readers a favor and just add a simple explanation under the conventions section, and I will be happy to close this bug. G. (In reply to comment #5) > I don't understand what this would add. > > Can you point me to a part of the spec that is not well-defined due to the > absence of something like what you propose? Something where without the text > you propose, there are multiple valid interpretations?
> As for multiple interpretations, it is obvious to the most naive reader that > both consequents may apply simultaneously, e.g., both of the following may be > true: > > * One byte in the range FE to FF > -> The whole sequence must be replaced by a single U+FFFD REPLACEMENT > CHARACTER. > * One byte in the range 80 to BF not preceded by a byte in the range 80 to FD > -> Each byte must be replaced with a U+FFFD REPLACEMENT CHARACTER. > > In this case, which of the two consequents apply? You may say the first? Why is > that? Why not the second? Since you have not bothered to explain this syntax, > either interpretation is valid. Yes, either is valid. They have exactly the same effect, so it doesn't matter. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: If there are specific places in the spec that are ambiguous, I'm happy to fix them, but relying on typographic conventions to define normative behaviour is a non-starter and as such I don't see any value in defining this particular typographic convention.
mass-move component to LC1