On Tue, 26 Jun 2001, Morten Jorgensen wrote:
>
> > * don't give an error for unresolved external functions, instead call a
> > new method BasisLibrary.unresolvedExternalF that throws a
> > RuntimeException; a good stylesheet uses xsl:if or xsl:choose to check if
> > these external functions are available so they don't get called if they
> > aren't.
>
> There is already a fix for this in the current CVS tree. I'll run some
> extra tests to see if there are some problems still. The compiler will
> check if the function-available() call is used and will never compile
> calls to any unavailable methods (xsl:if and xsl:choose that test purely
> on function-available() will be evaluated at compile-time).
I think that's not what the docbook stylesheets do; it does things like:
<xsl:choose>
<xsl:when test="contains($vendor, 'SAXON 6')">
<xsl:copy-of select="verb6:numberLines($rtf)"/>
</xsl:when>
So you only see at runtime whether the stylesheet intends to call the
unresolved function.
> > * Be careful about generated field and method names; any of these
> > characters is not allowed in them: %-.
> > So %rt% becomes $rt$, %as comes $as$ and any names that comes from a
> > stylesheet has - and . converted to $
> > This isn't perfect either, but it makes docbook work without verifier
> > errors.
> Good. The '%rt%' method names violate the JVM spec, but is still allowed
> by most JVMs, so this has been ignored for a long time.
Hmm, interesting. To get errors in the Sun VM, you need to use the -verify
option, or load it with a class loader, like with an applet. Didn't
anybody have problems with using xsltc in such a way?
> Very good, and very much needed. We've seen this problem with a few tests.
> This is another problem that we've put off for quite a while.
I understand. I think the only good solution is splitting into different
methods; when a method becomes bigger than 64 kb you get some other
problems as well.
> > * Change in XslAttribute; an xsl:attribute is allowed anywhere and adds
> > the attribute to the nearest containing result element. The check in
> > XslAttribute is not needed.
>
> I am not sure if I agree 100% here. Section 7.1.3 of the XSLT 1.0 spec
> states that it is an error to add attributes to an element E using the
> <xsl:attribute> element after adding child elements to E. Also, there
> are cases where some elements created with <xsl:element> are to be
> ignored and attributes have to be moved around - but only if they occur
> as the first child/children of an element.
Okay, I haven't gone too deep into the spec. The problem is with
constructs like these:
<element>
<xsl:if test="whatever">
<xsl:attribute name="foo">bar</xsl:attribute>
</xsl:if>
<xsl:attribute name="sadly_ignored">...</xsl:attribute>
</element>
The second xsl:attribute is ignored, because it is preceded with xsl:if;
this is however a correct XSLT construct.
> > * nwalsh'es stylesheets assume that "document('../common/l10n.xml')"
> > is taken relative to the root of the docbook stylesheets, but XSLTC takes
> > it relative to the current directory at runtime. I don't know who's right,
> > though XSLTC's position seems logical. However to make it work a symlink
> > from ../common in your current directory to its real location is
> > necessary to make it run.
> Hmmmm.... this could make a good discussion. Inputs, anyone?
Regards,
Erwin
