dleslie     00/08/22 13:28:23

  Modified:    xdocs/sources/xalan BUGS DONE
  Log:
  Draft of updates for 1.2.D02
  
  Revision  Changes    Path
  1.11      +0 -1      xml-xalan/xdocs/sources/xalan/BUGS
  
  Index: BUGS
  ===================================================================
  RCS file: /home/cvs/xml-xalan/xdocs/sources/xalan/BUGS,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- BUGS      2000/08/22 19:42:33     1.10
  +++ BUGS      2000/08/22 20:28:19     1.11
  @@ -4,7 +4,6 @@
   <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>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>UTF-8 output is improperly escaped in the 128-255 range.<br/><br/></li>
   <li>In a multithreaded environment, some threads may lose track of xsl:key 
elements.<br/><br/></li>
   <li>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.<br/><br/></li>
   <li>Implied HTML output (the output begins with &lt;HTML&gt;, 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 &lt;xsl:output 
method="html".../&gt; declaration in the stylesheet.<br/><br/></li>
  
  
  
  1.22      +5 -4      xml-xalan/xdocs/sources/xalan/DONE
  
  Index: DONE
  ===================================================================
  RCS file: /home/cvs/xml-xalan/xdocs/sources/xalan/DONE,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- DONE      2000/08/22 19:42:33     1.21
  +++ DONE      2000/08/22 20:28:20     1.22
  @@ -1,12 +1,13 @@
   <s3 title="Changes since &xslt4j; version 1.1">
   <p>For this release, we have applied several 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>The Xalan DTM (Document Table Model) was splitting text nodes containing 
entity references into multiple nodes. We have fixed this problem, and Xalan 
now it produces a single text node for output.<br/><br/></li>
  +<li>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.<br/><br/></li>
   <li>Norm Walsh submitted patches enabling Xalan to accept URI substitutions 
set by a custom EntityResolver.<br/><br/></li>
   <li>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.<br/><br/></li>
  -<li>We believe we have fixed encoding problems handling characters above 127 
in URI attributes. We are still soliciting input on how to handle special URI 
characters between 32 and 127.<br/><br/></li>
  -<li>The use of position() in sort expressions now works as expected, which 
makes it easy to reverse node order. When the primary sort fails completely, we 
no longer fall through to a sort with the secondary key.<br/><br/></li>
  -<li>Sergei Ivanov submitted a patch to avoid including a minus sign an ID in 
the rare case when a negative number was appearing in the ID.<br/><br/></li>
  +<li>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.<br/><br/></li>
  +<li>The use of position() in sort expressions now works as expected, which 
makes it easy to reverse node order.<br/><br/></li> 
  +<li>If a sort with the primary sort key fails completely, we no longer 
perform a sort with the secondary key.<br/><br/></li>
  +<li>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.<br/><br/></li>
   <li>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.<br/><br/></li>
   <li>Ed Staub submitted a patch so that a message about processing 
instruction names now appears as a warning rather than an error.<br/><br/></li>
   <li>A thread-safety issue in pattern matching was identified and 
fixed.<br/><br/></li>
  
  
  

Reply via email to