[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. 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 >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]