capitalization of true/false/TRUE/FALSE is inconsistent

[TallTed]

Noted while reviewing #343 and 17.4.2.2 sameValue, and then whole document. Booleans are usually but not always uppercase (TRUE/FALSE), and streaming prose is usually but not always lowercase. This is probably an issue across all WG documents.

To improve comprehension, I think these should be consistently uppercase at least when in a nominal boolean (as in "then return FALSE"), if not when in streaming prose (as in "then is true").

I would prefer consistent uppercase wherever TRUE/FALSE[/ERROR] are used. ("Truth" and variants should otherwise be treated as normal prose.)

[kasei]

I think improving consistency would be good,. I don't have strong feelings here, but I think it's worth calling out the argument in favor of using lowercased versions is that both the canonical xsd lexical form and the Turtle/SPARQL surface syntax short forms use lowercase.

[TallTed]

In the event the group chooses consistent lowercase, I suggest consistency also in monospace (instead of proportional) and possibly also bold, wherever the word is not meant to be read in its English sense (including but not limited to when its a boolean, xsd, Turtle, or SPARQL element).

[afs]

We can make them lowercase, different color. c.f. RDF documents .. but that leads to wanting to reformat everything else and we do not have time.

Semantic mark-up now would be largely possible.

[hartig]

I just noticed that this issue is a duplicate of #277. I propose to close #277 (instead of this one) because there is already more discussion here and no discussion in #277

[afs]

There at least 3 different kinds use of true

• General language "This statement is claimed to be true."
• The value is true (value space)
• xsd:boolean true/false (lexical space)

RDF Concepts (via reSpec) uses some color coding applied by <code>.

[TallTed]

that leads to wanting to reformat everything else and we do not have time.

If only I'd raised it earlier, like in September... Oh, wait, I did. :-(

[TallTed]

I strongly prefer all-caps for both value space and lexical space, when not general language. Doing so increases recognition that it is non-general language.

That said, it's not worth a Formal Objection, so I'll live with what the group decides, in hopes that a decision against me might be reconsidered for a future CR cycle.

[afs]

@TallTed - the lexical space is defined by XML Schema 1.1 - it is not a choice being made by this working group.

https://www.w3.org/TR/xmlschema11-2/#boolean

What is more, that XML Schema spec has a way of writing the values, and that style is the style used in RDF Concepts.

[TallTed]

@afs — I believe that many if not all instances of true/false in the text are expressing the value space, not the lexical space. This leads me to suggest styling those with the same representation as in the XML Schema 1.1 specification, i.e. —

boolean has the ·value space· of two-valued logic: {true, false}.

This also leads me to suggest that any instances of TRUE/FALSE (all caps) in any styling be changed to all lowercase.

All of this would apply to all documents in our suite.