[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xsl-list
Subject:    Re: [xsl] XSLT 2.0 compability issue occured in topicmerge.XSL in DITA OT1.5.1.
From:       team wise <dfanster () gmail ! com>
Date:       2012-09-25 9:48:44
Message-ID: CAPSg8o+jAVazJoeF18G34hHREZAD74t8mZHuTJJxF4OE6g=BWQ () mail ! gmail ! com
[Download RAW message or body]

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



2012/9/25, Michael Kay <mike@saxonica.com>:
> 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${file.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${file.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${file.separator}psmi.xsl">
> >  <factory name="net.sf.saxon.TransformerFactoryImpl"/>
> > <param name="WORKDIR"  expression="${dita.input.dirname}"/>
> > </xslt>
> > <replace dir="${dita.map.output.dir}" token="™" value="™‎"
> > 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@gmail.com>:
> > > 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@saxonica.com>:
> > > > 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
> > > > 
> > 
> 
> 
> --~------------------------------------------------------------------
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> or e-mail: <mailto:xsl-list-unsubscribe@lists.mulberrytech.com>
> --~--
> 
> 


-- 
Keep an Exacting Eye for Detail

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe@lists.mulberrytech.com>
--~--


[prev in list] [next in list] [prev in thread] [next in thread]