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 agree--paths in the suffix is not a good idea.


Eliot Kimber, Owner
Contrext, LLC

On 3/17/14, 10:31 AM, "Robert D Anderson" <robander@us.ibm.com> wrote:

>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
>Otherwise I agree with Chris' response.
>Eliot Kimber, Owner
>Contrext, LLC
>On 3/17/14, 10:01 AM, "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
>>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
>>(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
>> <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
>>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
>>- 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
>>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="..."> ...
>>  <topicref href="middle.dita">
>>   <ditavalref href="..."> ...
>>    <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
>> 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
>>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:

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