← Prev in month
← Prev in thread
Collection of questions about branch filtering
I've been going through review comments on elements related to branch filtering (there are a lot). Rather than send many emails, I'm grouping these related ones in a note, and sending a larger question as one additional note. 1. A little while ago, some of us got into a discussion about @keyref on <ditavalref>. Using @keyref seems to cause havoc for some processors - to evaluate properly, you would need to evalute @keyref on <ditavalref>, which enables you to get the information you need in order to evaluate @keyref on items in the branch. While there may be a use case for using @keyref on <ditavalref>, it does not seem worth the cost, so I'd suggest removing @keyref from this element to significantly simplify processing. 2. What does it mean when you use a <ditavalref> element that does not reference a set of DITAVAL conditions? 2a. If the branch only has one <ditavalref> - no filtering will take place - are child elements still used to rename files / keys? 2b. If the branch has multiple <ditavalref> - does this result in one unfiltered copy of the branch? 3. If nesting <ditavalref> inside a branch that already uses <ditavalref>, in what order are suffixes / prefixes added? For example, the initial <ditavalref> causes every file name to add "-mac" to the end; the second one adds a suffix of "-novice": <topicref href=""> <ditavalref href="" ... <dvr-resourceSuffix>-mac</dvr-resourceSuffix> <topicref href=""> <ditavalref href="" ... <dvr-resourceSuffix>-novice</dvr-resourceSuffix> <topicref href=""> In this case, the middle file for this branch becomes "middle-mac.dita". Is the last leaf node "leaf-mac-novice.dita", or "leaf-novice-mac.dita", or is this up to the implementation? 4. Comment that @lockmeta seems meaningless on <ditavalmeta> inside <ditavalref>. I agree and would suggest removing it. 5. For the <dvr-resourcePrefix> and <dvr-resourceSuffix> elements: these result in renamed documents, filtered with specific conditions - but what about documents we cannot filter? Specifically, does renaming affect external documents, peer documents, or local non-dita documents? 6. For those same elements: can you include directory information? For example - are these valid? <dvr-resourcePrefix>novice/<dvr-resourcePrefix> <dvr-resourcePrefix>http://example.com</dvr-resourcePrefix> 7. If using @copy-to in a branch with resource-prefix, which is applied first - the @copy-to value or the renaming of the original file? Think it must be the copy-to - otherwise for all copies of that branch, you would rename the filtered copy, then copy-to takes you back to single value. Another way of saying this could be - the resourcePrefix value applies to both the original href and to the copy-to value. Thanks, and sorry to say that more of these questions will be coming (but thanks everybody for the reviews). Robert D Anderson IBM Authoring Tools Development Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
← Prev in month
← Prev in thread