In addition to [B], ditac 2.0.3 now implements [A] (explanations below) in a way which is similar to what was done in ditac 1.x. We hope that you'll find this ``retrofitted'' implementation sufficiently powerful and reliable for your needs.
Ditac 2.0.3 should be released tomorrow. On 06/21/2011 09:04 PM, Douglas W Philips wrote: > On Tue, Jun 21, 2011 at 2:28 PM, Hussein Shafie <[email protected] > <mailto:[email protected]>> wrote: > > > Let's suppose your .ditaval file is: > --- > <val> > <prop action="exclude" att="audience" val="expert"/> > </val> > --- > > [A] With ditac 1.x, if you wanted to exclude myconcept.dita, you had to > specify audience="expert" on the <concept> element. > > <concept audience="expert"> > ... > </concept> > > [B] With ditac 2.x, let's suppose you map contains: > > <topicref href="myconcept.dita" /> > > if you want to exclude myconcept.dita, you must specify: > > <topicref audience="expert" href="myconcept.dita" /> > > ditac 1.x did not support [B]. In our opinion, [B] is more useful and > more intuitive than [A]. > > > We feel exactly the opposite. > > It is the topic author who adds conditional/filtering attributes on > content; the author who knows what filtering applies to the content > they've written. Sometimes filtering is at a small level, a 'ph'rase or > 'p'aragraph, and we all agree that this should be done this way. When > the author writes an entire concept that needs conditional/filtering > applied, for example details on a specific customer contract or feature, > it seems very strange to us that suddenly the conditional/filtering > should be applied, not with the content as it is for 'ph' or 'p', but > instead must be applied far away from the content, in a map file that > the author may not control. That adds a burden on authors and producers > to make sure that a map change doesn't accidentally ship content to a > customer who should not see it. > > This is a HUGE concern for us, as we have content that is used for both > external customers and internal purposes. > Sometimes the internal customer's get just a few words or paragraphs of > confidential/secret information, but sometimes we have entire concepts > that are sensitive and internal only. We certainly do NOT want to have > the conditional/filtering for those concepts separate and apart from the > content, off in maps where the confidentiality can be lost/forgotten, etc. > > Sorry for the strong language, but we feel very strongly that this is a > mis-feature in DITA (and we've gone public about it and have lost that > battle). We loved that DITAC (1.2.x at the time) "got it right!" > > > Now, we'll see what we can do to support both [A] and [B] in ditac 2.x. > However, I cannot promise that we'll succeed in removing this > limitation. > > > Understood. We are not holding our breath. > Given the uncertainty of a potential change, we will have to take steps > in our processing tools (which invoke DITAC) so that we can continue to > apply conditional/filtering attributes at the point closest to the > content (i.e. the topic/concept level); we will have to work out a way > to have conditional/filtering attributes programmatically applied to the > ditamap files before we invoke DITAC. > -- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
