Contributing author: Deborah Pickett
Date: Aug 16, 2006
Question: If I have both audience and platform attributes in my topics, do I have to specify at least one value for each attribute in my ditaval file to filter on both attributes?
Answer: If you don't specify any include/exclude properties for, say, platform, then all of the platform="" attributes in your topics will be ignored; they just don't feature in the filtering logic at all. This should make sense, because you haven't asked for any platform filtering to happen. Just as you haven't asked for any product filtering or otherprops filtering.
Question: I put attribute values for filtering into topic and text elements, not in the map files. Why do I sometimes get empty XML files created by the Toolkit?
Answer: What happens is you have a map with a topicref/@href to a file that has had its root element removed (hence is now an empty file, and not a valid DITA topic). The map reference becomes a dangling link, in just the same way as if you'd referenced a file that doesn't exist at all.
I know that it's tempting to want the topic itself to be aware of which platforms and which audience s it's useful for, but the DITA filtering model is unclear about whether it supports this, and DITA-OT certainly doesn't. (There's an open RFE on SouceForge, but it's been unlooked-at because it's unclear what is the "correct" behaviour.) The way I squint at it, by putting the filtering attribute on the topicref rather than the topic, I'm not precluding some mad fool for including the topic outside its natural scope in their own map, for some reason I haven't thought of. In that respect, it's promoting more (though perhaps not better) re-use.
You *can* mark a topic as being applicable to certain audiences through using the prolog tag, but that's got nothing to do with filtering, and more to do with how your topic might get indexed in a CMS. There is likewise an element.
Question: The hope here is that all the information about a single concept, reference, task, or generic topic could reside in the same file to simplify updates for all output variations. Thus, if a change like the filename of the product's installation executable changes, the person doing the doc update sees the data for all variations of installation instructions.
Answer: I get what you're saying. I wouldn't say that you're wrong, but there's a slight culture clash here, because bits of what you describe above are considered by some to be the domain of the content management system rather than the author. But we're getting into philosophical areas here, and it might be best if som eone from the DITA TC took over lest I put words in their mouth.
I will close, though, by expressing a suspicion that filtering isn't high up on DITA's list because DITA strives to solve the same problem by breaking up topics into pieces small enough that they can be shared using judicious conrefs and selected through careful use of maps. Extravagant use of filtering may be a sign that the author is either clinging to outmoded notions about sharing information in topics, or that DITA is the wrong hammer for their nail.