Support for mathmlref element

Right now I’m working on support for <mathmlref>. This is a subset of #1774, but I don’t expect to implement all of it in DITA-OT at this point so I’ve opened an issue specific to that element. (Once complete, whatever is done to make it work should be easily redone to make <svgref> work, a small subset of #1123)

The DITA specification says:

Processors SHOULD process the MathML as though the <m:math> element had occurred directly in the content of the containing <mathml> element.

http://docs.oasis-open.org/dita/dita/v1.3/os/part2-tech-content/langRef/technicalContent/mathmlref.html

I’ve got this part of the way done but have encountered a few issues:

1. <mathmlref> appears inside of a specialization of <foreign>, so the preprocess ignores it - the reference never registers. At this point I’ve set MATHML_D_MATHMLREF to the class value, as with other known class values, and added exceptions in DebugFilter.java so that it’s processed. This feels like a hack. I wouldn’t think this is appropriate for my own specializations. But this is an OASIS one, with an OASIS defined processing behavior, so it seems like we really should extend things to support it. For example: if (foreignLevel <= 1 || MATHML_D_MATHMLREF.matches(atts.getValue(ATTRIBUTE_NAME_CLASS))){
2. This feels very much like the <coderef> element. So I’ve used that debug filter to get the math targets added into .job.xml, because I expected a later step to pull in the math, much like with code references. But, I’m not sure this is the correct approach.
3. Again like coderef, I tried to add a SAX filter, in the same topic-fragment step – but it doesn’t use the XML catalog, so couldn’t parse the Math files (they have a DTD reference). I later heard from @jelovirt that the step which processes image metadata might be a good (catalog-aware) spot to add the filter, but I haven’t tried this yet.
4. I’m more comfortable in XSL anyway so I tried to do that instead - but the .job.xml file isn’t set up to retrieve only topics that use math, and throwing every DITA topic into a new XSL step is wasteful. Plus, so far, the files are processed in the source directory like code targets, and don’t exist in the temp directory.

At this point I decided to seek advice. What would the ideal approach be here?

[shaneataylor]

I also think there are synergies between implementing this correctly and implementing support for SVG (#1123).

[drmacro]

I see, I misread the original comment (I’ll blame cedar pollen and continuing illness). I was afraid some really significant bug had eluded all of us up to now.