Re: [dita] Collection of questions about branch filtering

[Chris Nitchie <chris.nitchie@oberontech.com>]

My quick opinions, for the record (a lot of these comments are mine):

1. Yes, remove @keyref and @conkeyref from <ditavalref>. A construct
cannot both control the contents of key spaces and reference keys. This is
the same case against mapref/@keyref contributing to key spaces.
2a: Yes, for ditavalref with renaming rules and no @href, renaming rules
should apply to the unfiltered branch, even when it¹s the only ditavalref.
(I question a bit whether this is a realistic edge-case.)
2b: Yes, ditavalref with no href results in an unfiltered copy of the
branch.
3. I suggest mandating an Œonion¹ approach, outer to inner, that is,
parentPrefix-childPrefix-name-childSuffix-parentSuffix.
4. Yes, dump @lockmeta on <ditavalmeta>.
5. Renaming should apply to local local only, but all formats, to avoid
breaking references to the renamed files, even though they are identical.
6. If directory paths are valid in copy-to, they should be valid in
prefixes. However, since suffixes are applied before the extension,
directory paths should be prohibited there.
7. I agree that resource prefixes and suffixes should apply to both @href
and @copy-to.

Chris

Chris Nitchie
(734) 330-2978
chris.nitchie@oberontech.com
www.oberontech.com
 <http://www.oberontech.com/>
Follow us:
 <https://www.facebook.com/oberontech>
 <https://twitter.com/oberontech>
 <http://www.linkedin.com/company/oberon-technologies>
 
 





From:  Robert D Anderson <robander@us.ibm.com>
Date:  Monday, March 17, 2014 at 10:39 AM
To:  dita <dita@lists.oasis-open.org>
Subject:  [dita] 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="root.dita">
  <ditavalref href="..."> ... <dvr-resourceSuffix>-mac</dvr-resourceSuffix>
  <topicref href="middle.dita">
   <ditavalref href="..."> ...
<dvr-resourceSuffix>-novice</dvr-resourceSuffix>
    <topicref href="leaf.dita">

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