Markdown in archetype definitions?

Specifications
21

Looks like we are getting close here.

My suggestion

  1. Support GFM in purpose, use, misuse.
  2. Use the algorithm to check if anything that is found may be markdown and if so render these fields accordingly when displayed. I.e. No special markdown flag.
  3. For simplicity and clarity, I would stick with what GFM (and typical libraries) supports out of the box as much as possible.
  4. Use markdown judiciously in these fields. Less may be more, especially all numbers exist as superscript and subscript in Unicode and thus won’t require markup; some selected letters as well (those that are typically used in math formulas).
  5. I don’t expect many problems with existing archetypes but if any come up the fields would need to be updated, probably very slightly so.

Based on that suggestion this leaves the following questions

  1. Should we support superscript via surrounding carets ^test^ and subscript via surrounding tildes: ~test~ This is typically available via extensions to GFM and could be enabled if desired.

  2. Related, but maybe less compelling, should we support strikethrough as well via double tilde:
    ~~This text can be interpreted as strikethrough.~~

  3. Should we allow the GFM supported HTML tags? This can typically be turned on or off (as a whole, not per tag). This relates to <b>, <i>, <s>, <u>, <code>, <pre>, <a>, <img>, <ul>, <ol>, <li>, <table>, <tr>, <th>, <td>, <blockquote>, <hr>. The only somewhat compelling reason to have it is for <u> to underline.

My opinion on these questions is

  1. Yes - support subscript and superscript using ^ and ~
  2. Maybe - strikethrough is far less compelling and slightly dangerous (either way)
  3. No. Why use markdown if what you really want to do is html? The advantage of markdown is its human readability without being too distracting if it is just rendered as plain text.
22

Based on discussions re PROMS I would also add Description to the list.

I think we might find that over time we actually extend this e.g. to annotations.

I’m fine with GFM. We will need underline, sub/superscipt (for some units) though agree numerics should be Unicode.

I agree we should not allow strikethrough, and am happy to use the caret/tildes

I agree we should avoid HTML tags but the only tricky area is which I think is supported in FHIR. I’d limit the HTML to

Getting really close.

23

You mean all descriptions in the ontology?

Not sure what you want to limit the html to, but in any case, I think this needs to be either all the GFM supported ones or none. You don’t have to use anything other than <u> of course (or whatever you had in mind), but starting to define and then implement specific extensions in all tools to support a different subset seems overkill.