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!"
OK. We are convinced. > > > 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. > Before implementing a workaround, please allow us for a few days to check whether supporting both [A] and [B] in ditac 2.0 is technically feasible. If this is feasible, we intend to release ditac 2.0.3 in the next few days. In such case, the files allowing us to reproduce the bug about the mangling of numeric ids (a bug that we were not able to reproduce) which would be really welcome. (Please understand that we would like to solve as much issues as possible for v2.0.3.) If supporting both [A] and [B] is not feasible, we'll send you an email confirming that you'll have a find a workaround. > Thanks for listening. > > -Doug > > > > > -- > XMLmind DITA Converter Support List > [email protected] > http://www.xmlmind.com/mailman/listinfo/ditac-support -- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
