Re: [xsl] XSLT 2.0 compability issue occured in topicmerge.XSL in DITA OT1.5.1.

[team wise <dfanster@xxxxxxxxx>]

Much appreciated Michael!
Let me give it a try.
Ray



2012/9/25, Michael Kay <mike@xxxxxxxxxxxx>:
> I haven't tried this, but I think you should be able to achieve the same
> effect as using -T from the command line by setting
>
> <factory name="net.sf.saxon.TransformerFactoryImpl">
>     <attribute name="http://saxon.sf.net/feature/traceListener";
> value="net.sf.saxon.trace.XSLTTraceListener"/>
> </factory>
>
> Michael Kay
> Saxonica
>
> On 25/09/2012 03:54, team wise wrote:
>> Hi Michael,
>> Further to my last message, to clarify, we apply Ant script when
>> invoking a transform.
>> For example:
>>
>>    <target name="semc.dita.topic.fo" description="Build SEMC XSL-FO
>> output from dita topic ( PDF Template)">
>>     <echo>Run semc.dita.topic.fo</echo>
>>      <condition property="args.xsl"
>>
value="${dita.script.dir}${file.separator}InfoShare${file.separator}xslfo${fi
le.separator}infoshare.dita2fo.shell.xsl">
>>        <not>
>>          <isset property="args.xsl"/>
>>        </not>
>>      </condition>
>>      <!-- Shell transformation -->
>>      <xslt processor="trax"
>>            in="${args.xsl}"
>>            out="${dita.map.output.dir}${file.separator}out.xsl"
>>
>>
style="${dita.script.dir}${file.separator}InfoShare${file.separator}xslfo${fi
le.separator}rename.xsl">
>>        <factory name="net.sf.saxon.TransformerFactoryImpl"/>
>>        <param name="WORKDIR" expression="${dita.input.dirname}"/>
>>      </xslt>
>>      <!-- Main transformation -->
>>      <xslt processor="trax"
>>            in="${input}"
>>
>>
out="${dita.map.output.dir}${file.separator}${dita.map.filename.root}.psmi"
>>            style="${dita.map.output.dir}${file.separator}out.xsl">
>>        <factory name="net.sf.saxon.TransformerFactoryImpl"/>
>>        <param name="output-related-links"
>>               expression="${args.fo.output.rel.links}"
>>               if="args.fo.output.rel.links"/>
>>        <param name="DITAEXT" expression="${dita.ext}" if="dita.ext"/>
>>        <param name="DRAFT" expression="${args.draft}" if="args.draft"/>
>>        <param name="ARTLBL" expression="${args.artlbl}"
>> if="args.artlbl"/>
>>        <param name="dflt-ext" expression="${fo.img.ext}"
>> if="fo.img.ext"/>
>>        <param name="WORKDIR" expression="${dita.input.dirname}"/>
>>      </xslt>
>>      <!-- PSMI transformation -->
>>      <xslt processor="trax"
>>
>> in="${dita.map.output.dir}${file.separator}${dita.map.filename.root}.psmi"
>>            out="${output}"
>>
>>
style="${dita.script.dir}${file.separator}InfoShare${file.separator}xslfo${fi
le.separator}psmi.xsl">
>>        <factory name="net.sf.saxon.TransformerFactoryImpl"/>
>>        <param name="WORKDIR"  expression="${dita.input.dirname}"/>
>>      </xslt>
>>      <replace dir="${dita.map.output.dir}" token="b"" value="b"b"
>> encoding="utf-8" includes="*.fo"/>
>>    </target>
>>
>> my question once again, how to apply that -T option to above?
>>
>> thank you in advance,
>> 2012/9/25, team wise <dfanster@xxxxxxxxx>:
>>> Hi Michael,
>>> thank you for your response.
>>> When i replied to it, my message was bounced back afterwards. My
>>> question is how to apply -T option. Could you please give me a pointer
>>> as a reference?
>>> You are absolutely right it is effectively an interoperability issue
>>> with XSLT2.0.
>>>
>>> Kind regards,
>>> RAY
>>> 2012/9/24, Michael Kay <mike@xxxxxxxxxxxx>:
>>>> Have you checked whether this is fixed in a later DITA release? You're
>>>> using quite an old one.
>>>>
>>>> If it reproduces with the latest DITA stylesheets, then it might be
>>>> useful to post sufficient information so that other people can
>>>> reproduce
>>>> the problem and perhaps diagnose the bug.
>>>>
>>>> With Saxon, the best way of diagnosing the bug is to run with the -T
>>>> option. This produces very voluminous trace output, of which the
>>>> interesting part is the last few instructions executed before the
>>>> failure occurred.
>>>>
>>>> Note that it's not entirely accurate to describe this as an XSLT 2.0
>>>> compatibility issue; it's more of a 1.0 interoperability issue that was
>>>> fixed in 2.0. Writing an attribute after writing children of an element
>>>> was an error in XSLT 1.0: "implementations may either signal the error
>>>> or ignore the attribute", so the stylesheet would fail with some XSLT
>>>> 1.0 processors and "succeed" with others. What has changed in 2.0 is
>>>> that all processors are required to behave in the same way (by
>>>> reporting
>>>> the error).
>>>>
>>>> Michael Kay
>>>> Saxonica
>
>


--
Keep an Exacting Eye for Detail