dita — archive

[Eliot Kimber]

I think that reasoning makes sense in general and it also makes sense for the Toolkit that the natural implementation decision would be to put any new processing, including keyref, after filtering. That seems to argue the general principle that filtering is first. I don't know that that principle is formally stated or clearly implied anywhere in the current spec. So I guess we really have two questions: 1. Does anyone disagree with the assertion that "filter first" is/should be the working principle of the DITA 1.2 standard? 2. If everyone agrees that "filter first" is the principle to apply to processing generally, does anyone disagree with the conclusion that key spaces must therefore reflect the effect of filtering? If the answer is "no" (no disagreement), then the action would be to update the language in "Indirect content inclusion: keys and conkeyref" under the "Linking and addressing" topic to include an explicit statement that filtering is applied before determining the key space and that the effective key space may include multiple definitions of the same key with different applicabilities. To recap, the implementation implication for "filter first" on systems that need to be able to calculate key spaces that reflect all possible sets of conditions used in a given information set is: 1. Either take a condition set (e.g., DIVAVAL document) as a parameter to the keyspace construction or 2. Return a keyspace that reflects not just unique keys but unique key/condition set pairs, meaning that there may be multiple instances of the same key reflecting different, unique sets of conditions. Note that by "keyspace construction" is implicitly meant also "key-to-resource binding lookup" since you can't resolve a key to a resource until you have first constructed the keyspace. The key mechanism already requires a root map as a parameter to the keyspace construction process. And again, this is primarily a practical issue for authoring and retrieval, not rendition processing. In general I think of authoring as involving both an authoring tool (editor) and a "link management service" that supports the editor by optimizing knowledge of links and addresses, in particular, what the set of available targets are (think I can address and therefore link to) and, for a given thing that *could* be addressed, that things do in fact address it (where used). I call this a "link management service", rather than content management, because it could be implemented as a standalone service applied to data that is otherwise not managed (e.g., topics on a file system or in a code control system or whatever) or it could be built into the editor (e.g., OxygenXML's built-in support for keys). However, one would normally expect link management services to be provided by more expansive content management systems that also provide versioning, access control, searching, and so on. Cheers, Eliot On 11/2/09 3:40 PM, "Robert D Anderson"