On 04/09/2012 04:53 PM, Orahood, Andy wrote:
> Following up on our conversation below, how horrible a project will it be to 
> try to rewrite the processor to reorder the filtering and conreffing steps? 
> Are the two functions, filtering and conreffing, modular enough that they 
> could be swapped?

Sure. See src/com/xmlmind/ditac/preprocess/PreProcessor.java, line 643 
to line 668:

---
...
if (!transcludeTopics()) {
     return null;
}

LoadedTopic[] loadedTopics = getAllTopics();
processRelatedLinks(loadedTopics);

if (!isAutoMap) {
     Filter filter2;
     if (filter != null) {
         filter2 = new Filter(filter);
     } else {
         filter2 = new Filter();
         configureFilter(filter2, outDir);
     }
     filter2.addExcludeProps("processing-role", "resource-only",
                             "print",
                             (media==Media.PRINT)? "no" : "printonly");
     filterMap(mapElement, filter2);

     addMetadata(mapElement);
}

if (filter != null) {
     filterTopics(loadedTopics);
}
...
---

However this change would probably break dozens of our tests and would 
probably make ditac useless for many of our users.

Please understand that, in the case of normal conref (i.e. not conref 
push), it makes really sense to perform filtering after conref-ing (AKA 
transcluding). If you do not do this, then the transcluded content will 
contain unwanted (non-filtered) contents.



> Could you give an estimate of how much work it would require?

No idea. Moreover we currently have no time to work on ditac. We have 
plenty of ideas to improve this component. However for now, our schedule 
forces us to work on our other products.




> Could we offer a bounty to you that would make it worth your while to fix?

Thanks, but this is unecessary. By insisting on this, you have already 
convinced us to try harder to fix the bug you have uncovered. However we 
currently cannot tell you whether or when this bug could be fixed.



> Could you give us pointers on how to approach the problem?

XMLmind DITA Converter is open source software. Please read its Java 
source code, starting with 
src/com/xmlmind/ditac/preprocess/PreProcessor.java. You'll see that this 
source code, though not trivial, is pretty well structured.




> We're stuck because our implementation was based on the behavior of the open 
> toolkit and now we don't have a fallback strategy.

Really sorry for that.



> The problem with your alternative solution is that we don't know for sure 
> prior to the document rendering whether the audience specified will exist in 
> any of the alternate titles so it could result in none of the titles being 
> rendered.

I'm sorry but I don't understand this. The approach I have described is 
routinely used, not only in DITA documents, but also in DocBook 
documents (DocBook ``profiling'').

May be, that on your side, you should also try harder to find a viable 
alternative.




>
> On 02/23/2012 04:32 PM, Orahood, Andy wrote:
>> I have a mechanism in my files to replace the default title when the correct 
>> audience is applied, that works like this:
>>
>> <topic id="kbdoc">
>>    <title id="default">test default title</title>
>>    <prolog>
>>      <data audience="ose">
>>        <title conref="#kbdoc/default" conaction="pushreplace">test OSE 
>> title</title>
>>      </data>
>>      <data audience="sakai">
>>        <title conref="#kbdoc/default" conaction="pushreplace">test Sakai 
>> title</title>
>>      </data>
>>    </prolog>
>>
>> When I run this transformation, even when I have a ditaval that sets the 
>> default action for conditional processing attribute "audience" to "exclude", 
>> the conref is done for both the "ose" title and the "sakai" title, and 
>> finally the "sakai" title is left in place of the default one. This is not 
>> how the Open Toolkit behaves, nor how I would expect ditac to handle 
>> filtering of conref content. I would expect that if the alternate titles are 
>> filtered out then the conref should not be processed. Only if I use a 
>> ditaval that makes the content in the data container for "ose" or for 
>> "sakai" visible should the conref be processed.
>>
>
> This is obviously a bug, but we cannot fix it without a major rewrite of
> ditac. (Conditional processing is performed by ditac after conref
> processing.)
>
> I would suggest this (may be naive) alternative:
>
> <topic id="kbdoc">
>    <title><ph audience="default">test default title</ph>
>           <ph audience="ose">test OSE title</ph>
>           <ph audience="sakai">test Sakai title</ph></title>
>
>

 
--
XMLmind DITA Converter Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/ditac-support

Reply via email to