Collection of questions about branch filtering

[Robert D Anderson <robander@us.ibm.com>]

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/)