For #2, you could do an identity transform on l10n.xml to resolve all
the entities in one go, then set the parameter l10n.xml to your custom,
resolved version of the file <xsl:param name="l10n.xml"
select="document('path/to/your/resolved/version/of/l10n.xml')"/>. That
should keep Firefox from every looking at the l10n.xml that's in the
distribution. Here's an xslt that does the identity transform:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:output method="xml" indent="no"/>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
For #1, perhaps you could log a bug and ask that VERSION be renamed to
VERSION.xsl in the distribution.
David
> -----Original Message-----
> From: Richard Rosenberg [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 04, 2008 10:05 PM
> To: [EMAIL PROTECTED]; [email protected]
> Subject: [docbook-apps] Re: client side transformation using
> docbook-xsl
>
> It is related. . .It's the cause.
>
> I thought it was the call to the document() function in
> l10n.xsl, but it is not. It is the failure to load external
> entities just as described in the article referenced below.
>
> My thanks to you, Mr. Cavicchio, for providing the timely
> information. Thanks to your information, and two
> expedient/crude hacks, I have client-side transformations
> working in Firefox 2.x and 3.0.
>
> The hacks:
>
> 1. To resolve a Firefox mime-type security error: Renamed the
> VERSION file to VERSION.xsl and updated docbook.xsl where the
> VERSION file is referenced (in an entity parameter
> declaration) to reflect the name change. On my Debian system,
> both files are located in
> /usr/share/xml/docbook/stylesheet/nwalsh/common/. Prior to
> this Firefox was complaining about the VERSION file missing
> the '.xsl' extension.
>
> 2. To resolve the Firefox failure to load external entities,
> I did what (I
> think) is an ugly, brute force thing. I simply inserted the
> contents of ../nwalsh/common/en.xml (less the xml version
> declaration at the top) into ../nwalsh/common/l10n.xml in
> where the '&en' parameter reference used to be.
>
> I'll probably replace all of the entity references in
> l10n.xml with the contents of the relevant locale specific
> xx.xml files in one go (python?) and just maintain it that
> way until something gets fixed. Needless to say, client-side
> transformations using Firefox are a critical requirement for
> me at the moment. And because this particular Firefox bug is
> alive and well in the version 3.0 beta release, I'll probably
> have to live with it for a while.
> At least it works in Firefox now, just like it "should," I guess.
>
> Thanks again for your swift and accurate response.
>
> Best regards,
>
> Richard Rosenberg
> piPPAT
>
>
> On Monday 04 August 2008 11:07:06 you wrote:
> > Richard Rosenberg [mailto:[EMAIL PROTECTED] wrote:
> > > I am having some trouble with client-side transformation using
> > > docbook-xsl via debian etch and apache 2.x. It works
> great with IE7,
> > > but firefox 2.x and 3.0 both display only the text
> (stripped of xml
> > > tags). Firefox also gives numerous messages about localization
> > > issues. I understand this may be a no-go with firefox for
> at least
> > > two reasons:
> >
> > Firefox does not read entities defined as files, perhaps this is
> > related?
> >
> > See
> >
> http://www-128.ibm.com/developerworks/web/library/x-ffox2/index.html?c
> > a=
> > drs-
> >
>
> ---------------------------------------------------------------------
> 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]
