Stream: implementers
Topic: Immunization - illegal markdown?
Richard Kavanagh (Nov 14 2016 at 23:27):
In the immunization resource at Immunization.reaction there is a comment containing "[[[AllergyIntolerance]]]". Is this legal markdown?
Lloyd McKenzie (Nov 14 2016 at 23:34):
Don't know if it's legal markdown or not, but the build tooling has been designed to handle it as a simple way to point to resource definitions
Richard Kavanagh (Nov 14 2016 at 23:35):
Well, to be pedantic it violates the markdown datatype definition in the spec...
Alexander Henket (Nov 14 2016 at 23:37):
According to Oxygen it is legal markdown, but renders with additional square brackets, so maybe not suitable for immediate consumption by a plain markdown tool
Alexander Henket (Nov 14 2016 at 23:39):
But apparently there are many flavours (u added after John Cleeses letter to the US) of markdown out there, and I don't know what Oxygen 'speaks'
Lloyd McKenzie (Nov 14 2016 at 23:41):
We pre-process the triple-square brackets before passing the content to the markdown processor. Not sure if there's a more markdown-compliant way of doing this short-cut, but I'd rather not get rid of the shortcut. (Agree it should be documented in the spec though.)
Alexander Henket (Nov 14 2016 at 23:53):
Potentially you could use your own scheme to stay within markdown and have the desired outcome. E.g.:
[AllergyIntolerance](x-doc-fhir:AllergyIntolerance)
Lloyd McKenzie (Nov 14 2016 at 23:59):
That defeats the point of not having to type a bunch of stuff . . . :(
Alexander Henket (Nov 15 2016 at 00:01):
Can't win 'em all :-) I just proposed something within spec. I definitely have other fish to fry, so I'll not pursue this one.
Grahame Grieve (Nov 15 2016 at 00:40):
I did mean to get around to pre-processing that out of the markdown when building resources that contain the markdown. can someone create a task for that?
Richard Kavanagh (Nov 15 2016 at 07:08):
Ok no big deal, but you have to realise that you creating shortcuts for yourself just pushes the complexity to others. The "build tool" is not the tool that has to cater for this stuff.
Grahame Grieve (Nov 15 2016 at 07:09):
it wasn't meant to slip outside the build tool
Grahame Grieve (Nov 15 2016 at 10:06):
Actually, I just ran into this in my own tooling, so I'm fixing it now
William Archibald (Nov 15 2016 at 18:09):
Core (daring fireball) Markdown is pretty sparse. Which is why you have various "flavors" of Markdown. GitHub-flavored Markdown and such. It wouldn't be unheard of to have that be an element of "FHIR-flavored Markdown"...
Lloyd McKenzie (Nov 15 2016 at 18:47):
Extra spicey . . . :)
Grahame Grieve (Nov 15 2016 at 21:16):
no but we'd rather avoid that
Eric Haas (Nov 16 2016 at 00:24):
For us build editors where are these markdown cheats listed? I didn't know about [[[resource]]]
Grahame Grieve (Nov 16 2016 at 02:55):
not documented anywhere as far as I can find
Lloyd McKenzie (Nov 16 2016 at 02:57):
I think that's the only customization. Where *should* we document it?
Grahame Grieve (Nov 16 2016 at 03:13):
In the spreadsheet wiki page, I think, because it's a spreadsheet thing. The documentation is [[[type]]] - build tool will replace with a correct reference to the type
Grahame Grieve (Nov 16 2016 at 03:13):
it does a little more, but I don't want to document that
Grahame Grieve (Nov 16 2016 at 03:16):
sorry, can also be [[[type.element]]] such as [[[ElementDefinition.max]]]
Lloyd McKenzie (Nov 16 2016 at 03:17):
So it won't work if specified in an XML structure definition?
Grahame Grieve (Nov 16 2016 at 03:17):
no. definitely won't work
Lloyd McKenzie (Nov 16 2016 at 03:19):
Is there utility in making it work?
Grahame Grieve (Nov 16 2016 at 03:21):
well, that depends on what you think about this whole stream. if you think that it makes sense for it to work outside the build tools, and us to just extend markdown, sure
Grahame Grieve (Nov 16 2016 at 03:21):
but I don't
Last updated: Apr 12 2022 at 19:14 UTC