You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Pa...@lotus.com on 2000/08/25 01:49:58 UTC
Xalan-J 1.2.D02 Developer's Release posted to xml.apache.org
Lords and Ladies,
This release contains bug fixes and a Xerces upgrade - it now supports
1.1.3.
This is also the first build to be build with the Ant build process, so
those of you
sick of using make files can find the new build files in the top-level
directory
(build.bat, build.sh, build.xml).
The zip and tar files can be found in the following directory:
http://xml.apache.org/dist/xalan-j/.
The following details are gleaned from the Release Notes that have yet to
be posted to the xml.apache.org website.
Enjoy!
For this release, we have applied several bug fixes, including
patches submitted by developers to Xalan Development Mailing
List. If you run across a problem with Xalan-Java, 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.
The Xalan DTM (Document Table Model) was splitting text
nodes containing entity references into multiple nodes. We
have fixed this problem, and Xalan now treats the node as a
single text node.
Norm Walsh submitted patches enabling Xalan to accept URI
substitutions set by a custom EntityResolver.
Gary Peskin submitted a patch enabling Xalan to process
expressions with path steps following a union. As a result,
Xalan can now transform documents of the DocBook document
type.
We now encode characters above 127 in URI attributes (in
some cases "garbage" characters were appearing). We are
still soliciting input on how to handle special URI
characters between 32 and 127.
The use of position() in sort expressions now works as
expected, which makes it easy to reverse node order.
If a sort with the primary sort key fails completely, we no
longer perform a sort with the secondary key.
Sergei Ivanov submitted a patch to avoid including a minus
sign in an ID in the rare case when a negative number was
appearing in the ID.
We believe we have fixed XPath retrieval of attributes
qualified with a namespace prefix. Other namespace fixes
enable the name() and namespace-uri() functions to be
applied to namespace nodes.
Ed Staub submitted a patch so that a message about
processing instruction names now appears as a warning
rather than an error.
A thread-safety issue in pattern matching was identified
and fixed.
The output of very small decimal fractions has been
improved.
We fixed a problem with keys that appeared when multiple
threads were using xsl:key concurrently.
We also updated the build process (Ant and Make) to avoid
creating a copy of the source tree, and we placed the Ant tool
in a new bin directory.
Open bugs:
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.
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.
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.
In a multithreaded environment, some threads may lose track
of xsl:key elements.
UTF-16 output encoding is not yet supported. Under Sun's
JDK 1.2.2, a suitable message is issued, but a stack dump
occurs under JDK 1.1.8 due to differences in
ByteToCharConverter.
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.
Workaround: put an explicit <xsl:output method="html".../>
declaration in the stylesheet.
In some cases, exclude-result-prefixes takes effect even
when the specified prefix appears in sub-elements, causing
output of unresolved prefixes. If you experience this,
please adjust your exclude-result-prefixes attribute.
The id() function doesn't work in some complex match
patterns.
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.
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.
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.
In a multithreaded environment, some threads may lose track
of xsl:key elements.
Need to verify which HTML element attributes should be
treated as URIs.
Bug reports that we have not yet confirmed:
We have a report that passing a long string value
(somewhere over 128 characters) to a template via
with-param caused an overflow problem under Solaris with a
Sun JDK. We have not seen the problem under Sun's JDKs
(1.1.8 and 1.2.2) on Win32. Additional reports are welcome.
We have a report that external entities can affect xsl:copy
in a DOM input scenario. An external entity that had no
attributes was causing improper copying, and adding an
attribute fixed the problem. To date we have been unable to
create the bug situation in our lab.
Paul - New build guy