Reply to: Ditamap Editor – "Update All References"March 23, 2010 at 3:48 pm
Thank you for your response.
>> First, to try to clarify the question of whether the OT throws errors when the @type attribute on a map doesn't match the topic type: The OT gives a “warning” message in the log file
Agreed. And in my own defense, I never referred to the messages as “errors.” 🙂 So the OT gives [WARN] and [INFO] messages when the type attribute on the map does not match the actual topic type. I will also add that many of these are duplicates. I seem to get both WARN and INFO for each occurence. And, aside from the extra messages in the log, the affect on the output could be nil or very minimal (“related” links might not sort correctly at the bottom of the topic output). However, the log for our online help system contains 65,749 of these messages! On a 74Mb log, that is approximately 45Mb of messages.
You are also right that most users do not notice these messages, but I do, and I prefer a clean build whenever I can get it. I tested a build today outside of the XMetaL-hosted OT and found that if I removed all type attributes from the map, the messages were gone. I have an interest in keeping the log files as small and accurate as possible because, in the absense of an industrial strength CMS system, we depend on our build logs to know when there are conref errors or other problems with our content that need fixing.
I also noticed that the WARN and INFO messages occur for the glossentry specialization.
>> There are a couple of reasons I can think of to not automatically populate the @type attribute with values corresponding to specialized topic types:
>> – Sometimes people create specialized topic types just because they want to add a new structural rule or use fewer element types. In these cases it is is appropriate to process a specialized topic exactly the same way that you would process an unspecialized topic. Using a different @type value would provide no benefit in these cases and would be one more thing that could go wrong in processing.
So long as the type attribute is set correctly, the specialized DTD has been added to XMetaL and the OT catalog files are up to date, I do not see what could go wrong with setting the type attribute to the correct topic type. It would have the benefit of producing cleaner log files.
>> It is conceivable that some processing tools could be hardcoded to allow only certain values for @type.
I would suggest that such a processing tool would not fully support DITA specialization, and as such, would be significantly flawed.
I would also like to add that I am sorry for referring to you as Susan in my previous post. Please accept my apologies for the mistake.