<div dir="ltr">Hello Javadoc developers,<br><br>below is a slight rephrasing of my comment on reddit. <span class="gmail-_28nEhn86_R1ENZ59eAru8S">u/pavelrappo</span> asked me to post it here, so that it can be better discussed.<br><br>> Alternate transformers could convert more Markdown constructs to HTML and JavaDoc tags.<br>><br>> ...<br>><br>> it would be possible to for there to be additional transformers that a client may choose to use that are adequate and sufficient for their needs.<br><br>I feel like it would be better for the JEP to go into some details about what kind of needs are these.<br>As a javadoc user, I'm mainly concerned with authoring and consuming javadoc documentation.<br>Most of the usage of javadoc tools that I've personally seen was mostly using default settings.<br>So for me it is not clear why I would want to convert more Markdown constructs to HTML and JavaDoc tags? Still it feels like a very important part of the proposal that can affect other pieces of the design.<br><br>Another note is that the problem as stated in the JEP feels like the same problem [described by Project Babylon](<a href="https://www.youtube.com/watch?v=xbk9_6XA_IY&t=889s">https://www.youtube.com/watch?v=xbk9_6XA_IY&t=889s</a>), different needs require different concentrations of syntactic sugar. Low level optimizations require low level assembly code (for javadoc this is probably HTML), some require more high-level elements, like javadoc links and some require full source code like original markdown. So maybe some ideas from Project Babylon can be borrowed to create a multi-level "Javadoc Model" that can be used in many different usage scenarios. <br><div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--<br></div><div>Victor Nazarov<br></div></div></div></div></div></div></div></div>