dita — archive

[Su-Laine Yeo]

(merging threads) Thanks Robert. I'm so sorry to have sidetracked the discussion. I am used to thinking that cutting scope from a project will get it out the door faster and with better quality, but I'm slowly learning that it's not the case here. So I'm not going to ask for scope reductions. That said, we still have the problems that I was hoping to address via scope reduction, i.e. the spec is big and certain parts of it are very difficult to understand. It is a problem for DITA adopters if they spend a lot of time trying to wrap their heads around features that will be of little practical benefit. Subject scheme maps have plenty of potential benefit, but only if there is support from tools, particularly authoring tools. If we don't have authoring tool vendors implementing a feature, then for the vast majority of adopters the feature is of little practical benefit. When I read things that are difficult to understand and unlikely to be of practical benefit to adopters, I want to save adopters from wasting their time trying to understand it. Can anyone suggest how to solve this problem? I don't have information I can provide publicly at this time about the XMetaL team's plans for supporting this feature. But as an informal observation on past public discussions, I haven't seen any signs of authoring tool vendors jumping up and down to implement it. JoAnn and Joel made good points about the need for controlled values. XMetaL does have a way to get a picklist of values into the authoring interface using DITA conditional processing attributes without specializing DITA (go to C:\Program Files\XMetaL 6.0\Author\Conditional Text\configs and edit the text file named ct_config.xml). It doesn't do everything that the Subject Scheme Maps feature prescribes, but it does the basic thing, which is define a list of allowed values that then appear in checkboxes in the UI. Su-Laine