OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Collection of questions about branch filtering

I don't think the spec has ever addressed the issue of directories inside of @copy-to, which in my reading means they are not forbidden. I know I've had at least a couple of my users try this, though in many cases my own tools report this as an error due to some processing limitations.

Based on Eliot and Chris's comments, I think that means we should also allow directories in the "prefix" portion. I'm inclined to disallow them in the suffix, regardless of what @copy-to allows.

I'm not sure if the same answer applies to absolute paths such as "http://example.com/directory/" as part of the prefix.

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)

Inactive hide details for Eliot Kimber ---03/17/2014 10:09:45---My intent for the filename prefix and suffix elements was that Eliot Kimber ---03/17/2014 10:09:45---My intent for the filename prefix and suffix elements was that they apply only to filenames, and the

From: Eliot Kimber <ekimber@contrext.com>
To: Chris Nitchie <chris.nitchie@oberontech.com>, Robert D Anderson/Rochester/IBM@IBMUS, dita <dita@lists.oasis-open.org>,
Date: 03/17/2014 10:09
Subject: Re: [dita] Collection of questions about branch filtering

My intent for the filename prefix and suffix elements was that they apply
only to filenames, and therefore could not be paths. But the behavior
should be consistent with @copy-to in general, so if @copy-to can
meaningfully specify paths then the filename prefix and suffix should as
well, I guess. Not that I would ever recommend that somebody do that,
since the results will be almost impossible to predict or manage, I should

Otherwise I agree with Chris' response.


Eliot Kimber, Owner
Contrext, LLC

On 3/17/14, 10:01 AM, "Chris Nitchie" <chris.nitchie@oberontech.com> wrote:

>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
>3. I suggest mandating an Œonion¹ approach, outer to inner, that is,
>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 Nitchie
>(734) 330-2978
> <
>Follow us:
> <
> <
> <
>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=""> >  <ditavalref href="" ...
>  <topicref href=""> >   <ditavalref href="" ...
>    <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
> documents, peer documents, or local non-dita documents?
>6. For those same elements: can you include directory information? For
>example - are these valid?
>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
> 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 (
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]