XSLT Coding practices in the DITA-OT

The core developers on the DITA Open Toolkit generally try to keep several coding practices and design patterns in mind when adding to the toolkit's XSLT code. If you are interested in digging around in the DITA Open Toolkit, or in contributing XSLT patches back to the core toolkit, you may want to keep these practices in mind:

•  Always use the specialized form to refer to elements. Never use a literal element name in an XPATH expression. (The one exception is the <dita> element, which does not have a class attribute). For example, instead of matching "table", match "*[contains(@class,' topic/table ')]". It's more verbose and a bit harder to read, but it's what makes specialized processing possible.
• Do not use priority attributes. The toolkit code is written to expect overrides (related to specialization or otherwise). If XSLT for one specialization uses priorities, then all overrides of that module must copy or increase the priority, making management difficult. It is better to simply let XSLT's native import precedence determine priority.
• Always use mode templates in place of named templates. Name templates are only appropriate for basic functions unrelated to the context, such as string operations ("get-extension"); although even basic functions also work as modes. The reason is that it is possible to override mode templates; in addition, it becomes easy to override a particular class of elements. For example, with a template named "addLinkingAttributes", you can only replace that template for every element. With match="*" and mode="addLinkingAttributes", you can create an override that updates your specialized <xref> but leaves <xref> itself untouched.