Language annotations on inline code

Language annotation on inline code works differently from on codeblocks. as this excerpt from the language docs explains.

Since decorations are just shortcuts for annotated phrases, you can add additional {annotation}s and {citation}s to decorations just as if they were regular phrases. The following annotates the inline code sample to specify its language.

            ```(sam)
                In Python 3, the correct form is `print("Hello World")`(python).

Notice that this is not the same as the language attribute on a codeblock. On a codeblock,

            ```(sam)
                ```(python)
                   print("Hello World")

the language attribute has a value of python, which corresponds to language="python". Whereas in inline example above specifies python as the type of the annotation, which corresponds to type="python".

An alternative is:

            ```(sam)
                In Python 3, the correct form is `print("Hello World")`(language "python").

Which is equivalent to `type='language' specifically='python'.

This raised two issues:

Is this confusing for writers? It can be hidden from writers to a certain extent by the schema designer, who can specify a limited enumeration of language types and language strings for each location, but this is complicated and has to be accounted for in code.
It creates a problem for the proposal for inline math (#96), where the first parameter should be interpreted as an encoding.

Potential solutions:

Flag all language attributes, including those on codeblocks. That way we avoid ambiguity, but it is a lot of extra typing on codeblocks.
Flag language annotations on inline code. But then it is inconsistent with codeblocks.
Special case inline code (it is a special case already) so that the first annotation is always a language attribute. But in that case how are other annotations treated. One option is to forbid any other unflagged annotations on inline code. In fact, it might not be a bad idea to forbid any typed annotations on other decoration types as well, since the foreseeable examples are all silly. In other words, bold and italic are escape valves for not having appropriate markup. Beside, it is easy to work around.
Special case a language attribute for inline code with something like angle brackets. print("Hello World")

The basic problem here is that we have an overlap between attribute syntax and annotation syntax. Not sure I want to revisit that at this point.

Seems pretty clear the most natural thing for writers would be to do `print("Hello World")`(python)

mbakeranalecta / sam

Language annotations on inline code #135