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
think.
Otherwise I agree with Chris' response.
Cheers,
E.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
On 3/17/14, 10:01 AM, "Chris Nitchie" <> 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
>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
>
>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 <>
>Date: Monday, March 17, 2014 at 10:39 AM
>To: dita <>
>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/)
>
>
>---------------------------------------------------------------------
>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:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
