dita — archive

[Robert Anderson]

Hi Eliot, > I see that the current 1.5 Toolkit does filtering before doing any other > processing. Is that a considered decision or just the way the implementation > fell? It was a considered decisions with regards to all other aspects of DITA processing, though we did not re-examine that decision in light of keyref. The reasoning has been discussed on this list and others, but it is primarily based on experiences that the IBM team had in the early (pre-standard) days of DITA. The two primary reasons to do it this way are 1) improve processing speed by dropping content you won't use as soon as possible, and more importantly 2) do not try and retrieve content that will never be needed. For example, if I have this: If I want to filter out all product A information, then I drop this early on in my processing. The build does not retrieve productA-info.dita, which may not even be available. The conref processing is also skipped, which saves a bit of time. The bigger issue for many of my own users is that when they package up information to send off to a translator, they do not need to ship productA-info.dita, because the conref is filtered out and never resolved. So, no money is wasted translating the file that will not be used. This issue, rather than the slight processing speed improvement, was the main one that resulted in the current processing order. As I said, when keyref came around, we didn't step back to re-address that issue, but it does make me wonder - if you have a key definition that wins with no ditaval, but is filtered out when you try to render the content, how could that key still be valid in your rendered files? I guess that's partly what you're asking. At this point I would expect the results you're getting from the OT today, but I'm obviously thinking about this from an OT style publishing perspective rather than from an editor or CMS perspective. Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit ekimber