[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Epub and Saxon: DOCTYPE revisited
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 hamilton@xmlpress.net 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 > bobs@sagehill.net > > -------------------------------------------------- > From: "Richard Hamilton" <dick@rlhamilton.net> > Sent: Wednesday, April 10, 2013 2:59 PM > To: <docbook-apps@lists.oasis-open.org> > 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 >> hamilton@xmlpress.net >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]