dleslie 00/10/13 08:27:18
Modified: xdocs/sources/xalan BUGS DONE
Log:
Final (I hope) doc updates for xalan-j 2.
Revision Changes Path
1.13 +8 -2 xml-xalan/xdocs/sources/xalan/BUGS
Index: BUGS
===================================================================
RCS file: /home/cvs/xml-xalan/xdocs/sources/xalan/BUGS,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- BUGS 2000/10/13 14:55:52 1.12
+++ BUGS 2000/10/13 15:27:10 1.13
@@ -1,7 +1,7 @@
<s3 title="Open bugs and bug reporting">
<p>Open bugs:</p>
<ul>
-<li>When format-number() should format NaN or infinity, it generates the
wrong string if default strings are used. Workaround: declare the strings in an
xsl:decimal-format instruction at the top of the stylesheet.<br/><br/></li>
+<li>When format-number() should format NaN or infinity, it generates the
wrong string if default strings are used. <em>Workaround:</em> declare the
strings in an xsl:decimal-format instruction at the top of the
stylesheet.<br/><br/></li>
<li>A "not serializable exception" occurs when you attempt to run a
precompiled stylesheet that expects parameter values to be passed in. If you
encounter this problem, you should forego the use of precompiled stylesheets
until a fix is available.<br/><br/></li>
<li>The namespace::* axis only selects namespaces that were declared locally
on the context node. Inherited namespaces are in effect; the only known flaw is
the lack of their presence on this rarely-used axis. The name() function, when
applied to a namespace node, returns a string that disagrees with other
processors, and the XPath spec is vague on this point.<br/><br/></li>
<li>Implied HTML output (the output begins with <HTML>, but the output
method has not been explicitly set to HTML) is not thread-safe, due to a "late"
change of output method. <em>Workaround:</em> put an explicit <xsl:output
method="html".../> declaration in the stylesheet.<br/><br/></li>
@@ -10,7 +10,13 @@
<li>If you specify HTML output and encoding via xsl:output, and if a
<HEAD> element is generated, then the encoding should be represented in a
<META> tag inside the <HEAD> element. We do not put out the META
tag nor any representation of the encoding in this case.<br/><br/></li>
<li>If you are generating processing instructions (PIs) in XML output, and
you attempt to insert a literal "?>" in it, the spec says that "? >" should be
generated, inserting a space to prevent interpretation as the end of the PI. We
do not take this special step, so "?>" is generated.<br/><br/></li>
<li>When outputting URI attributes in HTML, almost all "control" characters
below decimal 32 will cause an error to be raised, rather than silently being
discarded. Most characters above decimal 127 will be output as that character.
Percent should be output as %25 at all times (it is currently output as a
literal percent); this will be fixed later.<br/><br/></li>
-<li>Need to verify which HTML element attributes should be treated as
URIs.<br/><br/></li>
+<li>Need to verify which HTML element attributes should be treated as
URIs.<br/><br/></li>
+<li>The setDiagnosticsOutput() method does not cause redirection of all the
diagnostics that should be affected.<br/><br/></li>
+<li>If the use of an attribute value template for output (for example,
attrib="[EMAIL PROTECTED]) generates incorrect characters above decimal 127,
try using the "long form" instead (for example, <xsl:attribute name="attrib"
select="@title/>).<br/><br/></li>
+<li>When using document() with two arguments, the second attempting to
(re-)establish the base in the input document, the form
document(<ref>x</ref>,/) may raise an error. <em>Workaround:</em> Use
document(<ref>x</ref>,/<ref>doc</ref>) where <ref>doc</ref> is the outermost
element of the input document.<br/><br/></li>
+<li>Attribute sets and document() references in imported stylesheets should
be global, but are not.<br/><br/></li>
+<li>A variable can be declared with a qualified name(for example, my:var),
but later attempts to reference it (for example, $my:var) may
crash<br/><br/></li>
+
</ul>
<p>Bug reports that we have not yet confirmed:</p>
<ul>
1.26 +1 -1 xml-xalan/xdocs/sources/xalan/DONE
Index: DONE
===================================================================
RCS file: /home/cvs/xml-xalan/xdocs/sources/xalan/DONE,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- DONE 2000/10/13 14:55:54 1.25
+++ DONE 2000/10/13 15:27:13 1.26
@@ -1,6 +1,7 @@
<s3 title="Changes since &xslt4j; version 1.2.D02">
<p>We have applied a number of enhancements and bug fixes, including patches
submitted by developers to <human-resource-ref idref="xalandev"/>. If you run
across a problem with &xslt4j;, we strongly encourage you to write a patch and
submit it to us. We will review it to make sure it doesn't break something
else, and (assuming it doesn't) include it in our next release. In the interest
of fixing bugs, adding enhancements, and addressing a host of thorny design
issues, we sincerely want (and need!) your active participation in the ongoing
development of Xalan.</p>
<ul>
+ <li>&xslt4j; now suports UTF-16 output encoding.<br/><br/></li>
<li>We incorporated an updated BSF (support for extension elements and
functions) that supports Mozilla Rhino js.jar 1.5. The new bsf.jar replaces the
older bsf.jar and bsfengines.jar. <em>If you are using Javascript extensions,
you must now use js.jar 1.5. Mozilla Rhino 1.4 R3 is no longer
supported.</em><br/><br/></li>
<li>Costin Manolache submitted a patch that isolates all BSF-dependent
code in org.apache.xalan.xpath.XSLTJavaClassEngine.<br/><br/></li>
<li>We have added a custom processing instruction that you can use to
instruct the &xslt4j; processor not to cache an XML document.<br/><br/>
@@ -14,7 +15,6 @@
<li>We have improved the performance of keys by no longer allowing
<xsl:key> elements to use key() functions in the match or use
attribute.<br/><br/></li>
<li>Gary Peskin submitted a patch that fixes step pattern root
matches.<br/><br/></li>
<li>We fixed org.apache.xalan.xslt.TemplateList to match wildcard
patterns.<br/><br/></li>
- <li>&xslt4j; now suports UTF-16 output encoding.<br/><br/></li>
<li>Xalan now correctly observes import precedence when it evaluates a
variable declared and set in more than one
stylesheet.<br/><br/></li>
</ul>
