Re: [dita] Collection of questions about branch filtering

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

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

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