Prince XML vs Docbook

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:  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 <>)