This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11368 - Missing Typographic Convention - Switch Construct
Summary: Missing Typographic Convention - Switch Construct
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-22 01:28 UTC by Glenn Adams
Modified: 2011-08-04 05:36 UTC (History)
4 users (show)

See Also:


Attachments

Description Glenn Adams 2010-11-22 01:28:43 UTC
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
Comment 1 Ian 'Hixie' Hickson 2011-01-01 05:42:10 UTC
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.
Comment 2 Glenn Adams 2011-01-01 05:55:56 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2011-02-03 18:41:02 UTC
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.
Comment 4 Glenn Adams 2011-02-03 22:58:19 UTC
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 (&#x21AA;) 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
Comment 5 Ian 'Hixie' Hickson 2011-03-04 00:09:09 UTC
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?
Comment 6 Glenn Adams 2011-03-04 01:13:02 UTC
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?
Comment 7 Ian 'Hixie' Hickson 2011-05-05 21:51:58 UTC
> 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.
Comment 8 Michael[tm] Smith 2011-08-04 05:36:10 UTC
mass-move component to LC1