RE: [docbook-apps] Re: client side transformation using docbook-xsl

["David Cramer" <dcramer@motive.com>]

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:richrosenberg@earthlink.net] 
> Sent: Monday, August 04, 2008 10:05 PM
> To: Cavicchio_Rob@emc.com; docbook-apps@lists.oasis-open.org
> 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:richrosenberg@earthlink.net] 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: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: 
> docbook-apps-help@lists.oasis-open.org
> 
>