On Tue, Jun 21, 2011 at 2:28 PM, Hussein Shafie <[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. Thanks for listening. -Doug
-- XMLmind DITA Converter Support List [email protected] http://www.xmlmind.com/mailman/listinfo/ditac-support
