Subject: [xsl] Prince XML vs Docbook From: "Vasu Chakkera vasucv@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Thu, 18 Jan 2018 00:30:14 -0000 |
I came across a tool called Prince XML , which apparently works on Jason/XML and converts it to PDF or HTML or any format using CSS . I did not work on the publishing area for a while, but the last time I did, we were working with docbook , DITA, topics and applying XSLTs on the XMLS to generate XSL:FO documents for PDFs and XSLTs for HTMLS .. are there any good arguments for one or the other ? Are people still using the good old docbook XSLTs ? Any pros and cons for the Prince XML vs XSL:FO? Or am I comparing two totally different things? Vasu Chakkera On Jan 17, 2018 12:08 PM, "Michael Kay mike@xxxxxxxxxxxx" < xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > The "ambiguous rule match" doesn't mean there's anything wrong with this > pattern, it means there is more than one pattern that matches the same > nodes, and you haven't labelled them with a priority value to indicate > which one wins. > > Michael Kay > Saxonica > > On 17 Jan 2018, at 16:53, Kerry, Richard richard.kerry@xxxxxxxx < > xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > Michael, Martin, > Thank you both for your replies. > I knew the text() entries were not necessary but I'd left them in for > clarity (*). I had missed (ie not realized) the issue about string-values, > comments, etc. > > Martin, both of your versions gave "Ambiguous rule match". > Michael, having fixed one minor error, a spurious extra ')' immediately > before the final ']', I found that your version also gave "Ambiguous rule > match". > On giving a priority of 1 to the simpler filter and 2 to all your various > suggestions I am now finding it is working and giving the result I want (ie > all three options work). > > Was the ambiguous rule match because both are just classed as having a > filter, and the rule selection doesn't care that one has a more complex > filter than the other? > > > > > I had sort of realized that I was doing a join, though as I have very > little experience of database work I hadn't thought to use the term. > > > I am using Saxon 9.8.0.3 so XSL 2 is fine. I think 3 would be too but I > only have experience as far as 2. > > So thank you both, I am now able to get the results that I need. > > Regards, > Richard. > > (*) clarity in the sense that although it was more verbose I thought it > made my intent clearer. > > > [image: Blue line] > > *Richard Kerry* > BNCS Engineer, SI SOL Telco & Media Vertical Practice > > T: +44 (0)20 3618 2669 <+44%2020%203618%202669> > M: +44 (0)7812 325518 <+44%207812%20325518> > 4 Triton Square > <https://maps.google.com/?q=4+Triton+Square&entry=gmail&source=g>, > Regentbs Place, London NW1 3HG > richard.kerry@xxxxxxxx > <https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb993 44d708709a3177&URL=mailto%3arichard.kerry%40atos.net> > > > > > [image: Atos logo] > > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Atos group liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > > ------------------------------ > *From:* Michael Kay mike@xxxxxxxxxxxx <xsl-list-service@lists. > mulberrytech.com> > *Sent:* 17 January 2018 16:29 > *To:* xsl-list@xxxxxxxxxxxxxxxxxxxxxx > *Subject:* Re: [xsl] Nested filters, or filter too complicated. > > You're trying to do a join. That involves comparing items from two > different sets. > > In SQL (and in mathematical predicate logic) you do this by binding "range > variables" to the items in each set, and then using predicates such as > > where X.ref = Y.id > > You can use the same approach in XSLT, but with caveats. Only with XSLT > 3.0 are you allowed to bind variables within an XPath expression. But > that's where "." and "current() come in. Within a predicate, "." is used as > an implicit range variable for the set you are filtering. You can also > sometimes use "current()" as your second range variable. Or you can bind > variables explicitly using xsl:variable. The problem about using ".", > however, is that it changes its meaning in a nested predicate. > > In this case in XSLT 2.0 upwards, current() rescues you: > > match="type[.='Action'][$data/device-description/param[@ > name=current()/../base-name]/@standard='no')] " > > > (Note I've avoided the use of text() here. It's much better to compare > with the string-value of the element, rather than with its text nodes - it > will continue to work, for example, if the text is split up by comments). > > XSLT 2.0 defines that current() within a pattern refers to the node being > tested against the pattern. Unfortunately though (IIRC), XSLT 1.0 didn't > allow use of current() in patterns. But no-one is still using XSLT 1.0, are > they??? > > Michael Kay > Saxonica > > > On 17 Jan 2018, at 15:19, Kerry, Richard richard.kerry@xxxxxxxx < > xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > I am trying to use XSLT to process one XML file, which refers to data in > another, and I am having trouble with getting a filter to work. > > The first source file (device.xml) - the one that is actually processed > by the XSL - has entries like this: > > <device-description> > <device-value> > <base-name>PollNow</base-name> > <name>Poll Now</name> > <type>Action</type> > </device-value> > <device-value> > <base-name>StartupPollNow</base-name> > <name>Startup Poll Now</name> > <type>Action</type> > </device-value> > <device-value> > <base-name>Ping</base-name> > <name>Ping</name> > <type minimum-length="0" maximum-length="256" >String</type> > </device-value> > </device-description> > > One of the templates is approximately as follows: > > <x:template match="type[text()='Action']" > > <!-- do basic action. --> > </x:template> > > This quite happily matches all the <device_name> elements where the <type> > has a text value pf "Action". > > However, I have a second XML file (device-3.xml) which contains some data > that I wish to use to modify the behaviour of the transform. It has > entries like this: > > <device-description> > <param name="PollNow" standard="no" > > <name>Poll Now</name> > <description>normal poll</description> > </param> > <param name="StartupPollNow" standard="no" > > <name>Startup Poll Now</name> > <description>startup poll</description> > </param> > <param name="Ping"> > <name>Ping</name> > <description>Ping-Pong</description> > </param> > </device-description> > > The second file is accessed via a variable, as follows: > <x:variable name="data" select="document($in-file-3)"/> > > > What I want to achieve is that for all <type> elements where there is a > corresponding <param> where base-name is the same as param/@name, I want a > different action. > > The additional template I have for this is currently as follows > > <x:template match="type[text()='Action'][$data/device-description/param[ > @name=../base-name/text()]/@standard='no')] " > > <!-- do different action. --> > </x:template> > > My thinking is that the first filter is as with the first template I > listed, matching all <type> elements whose text is "Action". > The second filter should then enable me to pick the right param from the > second file, and do something based on the value of its @standard. > Maybe once I'm in the second filter I am causing confusion as to which > element the @name refers to (which should be the param) and which the > ../base-name is relative to (the device-value/type)? > > Can I do all this within a single template's @match ? Or am I making > it too complicated. In which case how might I get the result I'm looking > for? > > > Appreciatively, > Richard. > > > The examples are all slightly simplified from the real data, which has > more elements, and the transforms are in a mode. > > > > > *Richard Kerry* > BNCS Engineer, SI SOL Telco & Media Vertical Practice > > T: +44 (0)20 3618 2669 <+44%2020%203618%202669> > M: +44 (0)7812 325518 <+44%207812%20325518> > 4 Triton Square > <https://maps.google.com/?q=4+Triton+Square&entry=gmail&source=g>, > Regentbs Place, London NW1 3HG > richard.kerry@xxxxxxxx > <https://webmail.siemens-it-solutions.com/owa/redir.aspx?C=9fb20d019e3e4cb993 44d708709a3177&URL=mailto%3arichard.kerry%40atos.net> > > > > > [image: Atos logo] > > > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Atos group liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are > trading names used by the Atos group. The following trading entities are > registered in England and Wales: Atos IT Services UK Limited (registered > number 01245534), Atos Consulting Limited (registered number 04312380), > Atos Worldline UK Limited (registered number 08514184) and Canopy The Open > Cloud Company Limited (registration number 08011902). The registered office > for each is at 4 Triton Square, Regentbs Place, London, NW1 3HG.The VAT No. > for each is: GB232327983. > > This e-mail and the documents attached are confidential and intended > solely for the addressee, and may contain confidential or privileged > information. If you receive this e-mail in error, you are not authorised to > copy, disclose, use or retain it. Please notify the sender immediately and > delete this email from your systems. As emails may be intercepted, amended > or lost, they are not secure. Atos therefore can accept no liability for > any errors or their content. Although Atos endeavours to maintain a > virus-free network, we do not warrant that this transmission is virus-free > and can accept no liability for any damages resulting from any virus > transmitted. The risks are deemed to be accepted by everyone who > communicates with Atos by email. > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe (by email) > > > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe (by email) > Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are > trading names used by the Atos group. The following trading entities are > registered in England and Wales: Atos IT Services UK Limited (registered > number 01245534), Atos Consulting Limited (registered number 04312380), > Atos Worldline UK Limited (registered number 08514184) and Canopy The Open > Cloud Company Limited (registration number 08011902). The registered office > for each is at 4 Triton Square, Regentbs Place, London, NW1 3HG.The VAT No. > for each is: GB232327983. > > This e-mail and the documents attached are confidential and intended > solely for the addressee, and may contain confidential or privileged > information. If you receive this e-mail in error, you are not authorised to > copy, disclose, use or retain it. Please notify the sender immediately and > delete this email from your systems. As emails may be intercepted, amended > or lost, they are not secure. Atos therefore can accept no liability for > any errors or their content. Although Atos endeavours to maintain a > virus-free network, we do not warrant that this transmission is virus-free > and can accept no liability for any damages resulting from any virus > transmitted. The risks are deemed to be accepted by everyone who > communicates with Atos by email. > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <http://-list/293509> (by email) > > > XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list> > EasyUnsubscribe <-list/620062> (by > email <>)
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Nested filters, or filter, Michael Kay mike@xxx | Thread | Re: [xsl] Prince XML vs Docbook, Liam R. E. Quin liam |
Re: [xsl] Nested filters, or filter, Michael Kay mike@xxx | Date | Re: [xsl] Prince XML vs Docbook, Liam R. E. Quin liam |
Month |