Generalize vendor-specific markup in figures

[henrikt-ma]

We have discovered the need for choice of display unit for variable replacements in figures. While this could eventually become standardized, what is needed in the short term is a way to express this using vendor-specific information. The currently allowed used of vendor-specific markup would require awkward nesting of markup constructs, so we propose to rather equip both variable replacements and links with vendor-specific markup.

By not only proposing a solution for variable replacements, we want to ensure that we come up with a reasonably consistent design that covers vendor-specific handling of:

• alternative content
• fine control over variable replacements
• fine control over links

The proposed syntax for links, %[text]__AVendor(data)(url) may not seem obvious at first, but please note that %__AVendor(data)[text](url) is already defined to be parsed as %__AVendor(data)[text] (vendor-specific alternative content) followed by (url).

In summary, this PR proposes that there should be a total of three ways to attach vendor-specific markup (in order corresponding to the list above):

• %__AVendor(data)[text] (already standardized)
• %__AVendor(data){variable}
• %[text]__AVendor(data)(url) or %__AVendor(data)(url)

[henrikt-ma]

@casella, I am adding you as a reviewer primarily due to your role as a representative of MAP-Lib, since I find it important that MAP-Lib is following the development of the figure features of Modelica in order that it can be adopted (more broadly than a single example) by the MSL.

[henrikt-ma]

Regarding the awkward alternative of nested constructs for display unit selection, this is what it could look like, not forbidden by the current specification:

%__AVendor(?displayUnit=mm)[%{integrator.y}]

Related, it seems unfortunate to me that the current specification does not forbid putting a link in the text of another link:

%[foo %[bar](url2) baz](url1)

If we introduce a dedicated way for vendor-specific handling of variable replacements, perhaps we should generally forbid the use of nested markup for all combinations of variable replacements, links, and alternative content? Of course, it would be backwards a backwards incompatible change, but I see a good chance that nobody has put nested constructs like this in any library yet. The benefit would be that we lower the barrier for tools to achieve correct implementation, and we resolve the question about how to present nested links.

If there is popular demand in the future, we can relax the unnecessary restrictions then, like allowing variable replacements inside the other constructs.

[HansOlsson]

These are not easy to read for me, and I'm a bit hesitant to add something for future changes.

[henrikt-ma]

These are not easy to read for me, and I'm a bit hesitant to add something for future changes.

Please feel free to suggest alternative syntax.

The new example about future changes was just a continuation of the example we already have for vendor-specific content. Of course, it can be omitted if it is considered too obvious what vendor-specific markup for variable replacement could be used for.