OASIS Darwin Information Typing Architecture (DITA) TC

 View Only
  • 1.  Collection of questions about branch filtering

    Posted 03-17-2014 14:40
    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/ )


  • 2.  Re: [dita] Collection of questions about branch filtering

    Posted 03-17-2014 15:02
    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/ )


  • 3.  Re: [dita] Collection of questions about branch filtering

    Posted 03-17-2014 15:10
    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="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 > >


  • 4.  Re: [dita] Collection of questions about branch filtering

    Posted 03-17-2014 15:32

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






  • 5.  Re: [dita] Collection of questions about branch filtering

    Posted 03-17-2014 15:35
    I agree--paths in the suffix is not a good idea. Cheers, E. ————— Eliot Kimber, Owner Contrext, LLC http://contrext.com 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 >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="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 >> >> > > >