dita2html: warning for undefined element

Currenty when there is no template for an element the default rule will fire that generates some bold text wrapper with yellow background (in dita2htmlImpls.xsl). And the comment even says

><!-- (this rule should NOT produce output in production setting) -->

I think a warning on the console (xsl:message) would be much more appropriate to avoid such an element slip to production. Possibly the behavior could be toggled by a new parameter.

BTW: I didn’t find a way to override this rule by my custom plugin without overriding all other rules as well. So I had to patch the original DITA-OT code. (And hope I remember it when upgrading to a new version.) Is there a better way?

[jelovirt]

This has probably been in DITA-OT since 1.0. The correct way would be to use xsl:message to terminate processing completely, since it’s a bug in the code if we ever have to fall back to default templates for elements.

@robander what’s your take, should we treat this as a fatal error in DITA-OT 3.0. It’s not like anyone will actually want the yellow warning in their production output and IMO this equivalent to throwing a RuntimeException in Java for programming errors.

[robander]

I’m fine with a terminating message.

I can see how overriding a fallback rule that’s explicitly there to match "*" is going to be … difficult to customize, if you want to turn off the message, change it, or insert your own debugging material. Maybe we could handle that with a common mode template, rather than common named template? Go from today’s:

<xsl:template match="*" name="topic.undefined_element">
   .... write out a bunch of ugly stuff ...
</xsl:template>

to a common:

<xsl:template match="*" name="topic.undefined_element">
  <xsl:apply-templates select="." mode="handle-undefined-element"/>
</xsl:template>
<xsl:template match="*" mode="handle-undefined element">
  ... message and termination ...
</xsl:template>

That seems to have the most flexibility, and lets me override that mode to handle fallback in my own way in different transform types?

[All that said: in out-of-the-box cases this should only show up if something is truly broken, like DITA-OT forgot to code for some core element. I’ve only seen it come up on the rare case where somebody puts their own value in @class, or when working on a specialization and I have a typo in @class.]