Hi Bob, Thanks for the information. That explains what was going on, though it seems more like a Saxon 6 bug than a quirk:-).
I had thought that I was through with epub2, but it turns out that there are some distributors out there who still only accept epub2, even if your epub3 doesn't do anything exotic. Best Regards, Dick ------- XML Press XML for Technical Communicators http://xmlpress.net [email protected] On Apr 11, 2013, at 9:09 AM, Bob Stayton wrote: > Hi Dick, > Generally, it is the last import that takes precedence, so putting > outputset.xsl first would not have an effect. The issue with Saxon 6 is that > once the xsl:output doctype attribute values are set to some nonblank value, > they cannot be unset to blank by a later import. As long as xhtml-1_1 is > included in the import chain, Saxon cannot reset it to nothing. It seems to > treat doctype-system="" the same as a missing attribute, and does nothing > with it. This is a Saxon 6 quirk. > > Bob Stayton > Sagehill Enterprises > [email protected] > > -------------------------------------------------- > From: "Richard Hamilton" <[email protected]> > Sent: Wednesday, April 10, 2013 2:59 PM > To: <[email protected]> > Subject: [docbook-apps] Epub and Saxon: DOCTYPE revisited > >> Regarding Bob Stayton's message from a few days ago concerning Saxon not >> allowing a customization to override a DOCTYPE: >> >>> Actually, once a doctype has been set by an xsl:output statement, a >>> customization cannot reset it to nothing in Saxon. That's a quirk of Saxon, >>> confirmed by Michael Kay. The epub stylesheet imports the >>> xhtml-1_1/docbook.xsl >>> stylesheet that sets the doctype. The stylesheet tries to reset that to >>> empty, >>> and succeeds with xsltproc, but does not succeeed with Saxon. >>> >>> You might try the epub3 stylesheets, which don't have this problem. The >>> other >>> solution is to create your own version of xhtml-1_1/docbook.xsl that has an >>> xsl:output statement without doctype, and then your own version of >>> epub/docbook.xsl that imports it. >> >> Reading this, I thought you might be able to do a workaround like the >> following (this assumes you have a customization that imports >> epub/docbook.xsl): >> >> 1) Create an xsl file (I'll call it outputset.xsl) that contains just the >> following: >> >> <?xml version='1.0'?> >> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; >> version="1.0"> >> <xsl:output method="xml" encoding="UTF-8" indent="no" /> >> </xsl:stylesheet> >> >> 2) Import that file in your customization before importing epub/docbook.xsl. >> E.g., >> .... >> <xsl:import href="outputset.xsl"/> >> <xsl:import href="...../epub/docbook.xsl"/> >> .... >> >> Since outputset.xsl gets imported before either epub/docbook.xsl or >> xhtml-1_1/docbook.xsl, it would seem like this xsl:output method would >> prevail. However, when I tried this it had no effect. >> >> My question is, am I misunderstanding the import mechanism, are the contents >> of outputset.xsl incorrect, or is something else going wrong? >> >> I'm going to go ahead with Bob's suggestion, but any ideas/explanation >> concerning why this workaround doesn't work would be welcome. >> >> Best Regards, >> Dick Hamilton >> ------- >> XML Press >> XML for Technical Communicators >> http://xmlpress.net >> [email protected] >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
