I’d say this:
It is an error if the format of the content referenced by the @href attribute is different from that specified by the @format attribute, and processors SHOULD report the error. Additionally, processors MAY recover from the error by adjusting the processing algorithm for the referenced content to one appropriate for the actual format.
Chris
Chris Nitchie
Follow us:
From: Robert D Anderson <robander@us.ibm.com>
Date: Thursday, March 13, 2014 at 6:37 PM
To: dita <dita@lists.oasis-open.org>
Subject: [dita] Question about what it means when @format conflicts with actual format
Jarno posed an interesting question about the @format attribute:
-------------------------
If the @format value specified in linking element conflicts with the format of the link target, what should processor behaviour be?For example, if you have <topicref href="" format="html"/> and topic.dita is a DITA topic, should the processor throw an error or warning and keep processing the link using the format information in the target? Or, is a processor allowed to ignore topic.dita for e.g. key and conref processing, because the reference to it was HTML?
Another example, if you have <topicref href="" and the default format value is "dita", is a processor allowed to skip the map.ditamap for key space building and other map related processing?
Thus, is @format a processing hint for the processor and allows for optimizations like not trying to parse HTML as a DITA topic/map, or is it a processing constraint that forces a processor to treat a link in the way @format attribute defines the link target.
------------------------
In a lot of my own DITA work, I've added special checks that throw errors for (to my users) common mistakes. For example, format="ditamap" when the target doesn't reference something with a ditamap extension, and any inherited non-dita format value when the extension is actually "dita". Most of the related processing uses the explicit value, rather than correcting, but the error gives authors a chance to correct things when that is not the right action.
I doubt that everybody does that. I would resist updating the spec to state that processors SHOULD or MUST ignore the stated format and use the actual format, but beyond that I think either clarification is probably legal within the constraints of DITA 1.3 -- that is, either it's a hint that processors can use for optimizations (up to author to get it right), or it's a constraint that says "this IS the format I'm declaring".
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
Bob Thomas