underscore vs. dash

[rickj]

The technique documents use an underscore to separate words in a variable, but a dash to separate words in an ID (which is how they are in https://github.com/w3c/publ-a11y/blob/main/a11y-meta-display-guide/2.0/draft/localizations/en-US/display_guide_vocabulary_w3c_en-US.json)

My developers want to understand if this is a final decision, or if there is any potential for a harmonization of these.

[GeorgeKerscher]

When you state, "or if there is any potential for a harmonization of these." It sounds like your developers would like to use one or the other in all places, right?

What is the advantage or disadvantages of that? It seems that the variables using an underscore and the IDs using a dash is a feature; it makes it easier to differentiate.

Not doing coding, I would just like to know.

[mattgarrish]

One issue with hyphens in the json keys is that they aren't legal in javascript identifiers.

For example, you couldn't reference jsObject.conformance.conformance-title as the hyphen would be interpreted as a minus sign.

It's not the end of the world, as you can still use brackets to escape the key: jsObject.conformance["conformance-title"]

If you use underscores in the json, though, there wouldn't be an issue: jsObject.conformance.conformance_title

[bvandorn]

Our main concern here is consistency with the drafts.

A good example can be seen here https://w3c.github.io/publ-a11y/a11y-meta-display-guide/2.0/techniques/epub-metadata/#understanding-the-variables-5

If we look at the variable flashing_hazard and compare that to what we have in the json hazards-flashing there's an inconsistency here that can lead to confusion for publishers as well as developers looking to match these up in a downstream application looking to display the information.

[GeorgeKerscher]

@gregoriopellegrino

Does the JSON file need to be regenerated from the techniques and guidelines? Will that resolve inconsistencies?

[gregoriopellegrino]

This is correct because they are two different things:

• flashing_hazard is the name of the variable that is true if the metadata "flashing hazard" is present, it is false if it is absent
• hazards-flashing is the ID of the string to be shown to the user "

I would keep the two divided, because not all variables have 1:1 correspondence with a string to be shown. For example, we have both the variable flashing_hazard and no_flashing_hazards, the first shows a string on the screen (ID: hazards-flashing), the latter is used to calculate the algorithm, without any output for the user.

[bvandorn]

That makes sense that one is attributed to the id of a string and the other refers to the variable, the closeness in similarity still might be confusing. When it comes to the example you provided, I have a question:

For example, we have both the variable flashing_hazard and no_flashing_hazards, the first shows a string on the screen (ID: hazards-flashing), the latter is used to calculate the algorithm, without any output for the user.

I would expect the variable flashing_hazard of true to show the string hazards-flashing and if false, to not have any output.

no_flashing_hazards is a feature, that confirms that there is no flashing hazard (where flashing_hazard false does not confirm anything) and would be used to display an output to the user that there are no flashing hazards present.

If both are false or not present, the draft leads me to believe that a warning should be shown that flashing hazards may exist.

[gregoriopellegrino]

That's right, the logic by which variables are parsed to generate an output is in the algorithm section: https://w3c.github.io/publ-a11y/a11y-meta-display-guide/2.0/techniques/epub-metadata/#instructions-5