Question about what it means when @format conflicts with actual format

[Robert D Anderson <robander@us.ibm.com>]

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/)