[Bug 2776] New: - apply-templates without select doubles position()

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2776 *** shadow/2776 Tue Jul 24 20:43:17 2001 --- shadow/2776.tmp.26738 Tue Jul 24 20:43:17 2001 *** *** 0 --- 1,23 + ++ + | apply-templates wi

CVS access

Is anyone else having problems accessing CVS? I did a traceroute and there appears to be an infinite loop on the way from me to cvs.apache.org. My packets keep bouncing between 64.15.192.210 and 64.15.192.209. Gary

RE: Xalan-C++ bug: xsl:number not reporting correct info

Hmm, I'm using Saxon 6.2.2 and both versions of the stylesheet work fine. With Xalan-C++, Mike's version does not work, while mine does. Dave "Brian

RE: Xalan-C++ bug: xsl:number not reporting correct info

> The following works correctly: > >Figure ="chapter"/>. count="figure[not >(@numbered='no') or not(@numbered)]"/> > > Mike's version does not. I think that his version works with Saxon but your version does not. And he is/was using Saxon as his processor.

Re: Xalan-C++ bug: xsl:number not reporting correct info

The following works correctly: Figure . Mike's version does not. Dave David_Marston @lotus.c

Re: Xalan-C++ bug: xsl:number not reporting correct info

Mike Hostetler says he's getting a bad number from We have quite a few tests for xsl:number, so I'm concerned that this was able to slip through. Since count is a pattern, you should be able to say count="chapter" and get the same result. Mike: can you try that and report if it makes any differ

Re: Xalan-C++ bug: xsl:number not reporting correct info

Hi Mike, Thanks for the bug report. Could you create a posting in Bugzilla so we can track this? Here's the link: http://nagoya.apache.org/bugzilla Thanks! Dave Mike.Ho

Xalan-C++ bug: xsl:number not reporting correct info

For some reason, xsl:number in Xalan-C++ 1.1 (on Windows - haven't tried this on another platform) seems to have problem reporting correcting consisently. Example: The XML: The XSLT: http://www.w3.org/1999/XSL/Transform"; version="1.0"> Chapter

Re: Testing.

The regression suite is checked in as the "test" directory of the Xalan source repository. I think it's on the order of 15MB of test drivers, test files, and "golden" results.

[Bug 2772] - XPath not locating nodes in default namespace

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2772 *** shadow/2772 Tue Jul 24 13:38:23 2001 --- shadow/2772.tmp.23160 Tue Jul 24 13:38:47 2001 *** *** 63,65 --- 63,70 --- Additional Comments From [EMAIL PROTECTED] 2001-07-24 13:38 --- Created an attach

[Bug 2772] - XPath not locating nodes in default namespace

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2772 *** shadow/2772 Tue Jul 24 13:37:51 2001 --- shadow/2772.tmp.23151 Tue Jul 24 13:38:23 2001 *** *** 58,60 --- 58,65 --- Additional Comments From [EMAIL PROTECTED] 2001-07-24 13:37 --- Created an attach

[Bug 2772] - XPath not locating nodes in default namespace

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2772 *** shadow/2772 Tue Jul 24 13:36:39 2001 --- shadow/2772.tmp.23142 Tue Jul 24 13:37:51 2001 *** *** 53,55 --- 53,60 --- Additional Comments From [EMAIL PROTECTED] 2001-07-24 13:36 --- Created an attach

[Bug 2772] - XPath not locating nodes in default namespace

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2772 *** shadow/2772 Tue Jul 24 13:35:26 2001 --- shadow/2772.tmp.23103 Tue Jul 24 13:36:39 2001 *** *** 48,51 When I submit 'yatra' as XPath query, nothing is found. ! However '.' returns the 'yatra' node. --- 48,55

cvs commit: xml-xalan/test/java build.xml

curcuru 01/07/24 13:33:39 Modified:test/java build.xml Log: Add cheap-o 'dist' target to simplify posting full .zips of test suite Revision ChangesPath 1.25 +24 -0 xml-xalan/test/java/build.xml Index: build.xml

Re: getNodeValue() Problem

You are getting the Element "name". That element contains a child text node. That node in turn has the value you want. Try: String name = action.getElementsByTagName("name").item(0).getFirstChild().getNodeValue(); Jim. [EMAIL PROTECTED] wrote: > > Hi, > > I have got your mail id from Apach

[Bug 2772] New: - XPath not locating nodes in default namespace

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2772 *** shadow/2772 Tue Jul 24 13:35:26 2001 --- shadow/2772.tmp.23092 Tue Jul 24 13:35:26 2001 *** *** 0 --- 1,51 + ++ + | XPath not locating

Testing.

I'm interested in the testing that has been done on Xalan, but the testing portion of the site has said "Sorry! Xalan testing docs are temporarily being rebuilt! " for quite some time. Is a test suite available? Will the testing page ever come back? Thanks, cagey

Possible Bug in not

Not sure if this is the correct place to submit this problem to (found a work-a-round and thought I'd mention the problem to someone tho). Here is my XSLT: or Here is a snippit of XML that this operates

Re: getNodeValue() Problem

That isn't a Xalan question, and really belongs in another list. Brief answer: An Element has no nodeValue; look at its child nodes. See the DOM spec, or a DOM programming tutorial, for details.

getNodeValue() Problem

Hi, I have got your mail id from Apache site. I getting Null when I use getNodeValue(); I need to read the data between a Tag. Example, Srinivas. I need the name value 'Srinivas'. I am using the following for it. Element name=(Element)(action.getElementsByTagName("name").item(0)); where acti

[Bug 1506] - xsltc ingores exclude-result-prefixes attribute of LRE

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1506 *** shadow/1506 Tue Jul 24 10:32:25 2001 --- shadow/1506.tmp.21865 Tue Jul 24 11:36:34 2001 *** *** 52,55 --- Additional Comments From [EMAIL PROTECTED] 2001-07-24 10:32 --- ! Conformance test lre03 dem

cvs commit: xml-xalan/java/src/org/apache/xalan/transformer TransformerIdentityImpl.java

garyp 01/07/24 11:32:19 Modified:java/src/org/apache/xalan/transformer TransformerIdentityImpl.java Log: Fixed bug 2758 (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2758). The flag indicating that a call to startDocument() in the resultContentHandle

[Bug 2758] - Call to transform() resets output properties

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2758 *** shadow/2758 Mon Jul 23 23:35:45 2001 --- shadow/2758.tmp.21850 Tue Jul 24 11:32:42 2001 *** *** 2,9 | Call to transform() resets output properties | +---

[Bug 1506] - xsltc ingores exclude-result-prefixes attribute of LRE

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1506 *** shadow/1506 Sun May 20 17:26:07 2001 --- shadow/1506.tmp.20840 Tue Jul 24 10:32:25 2001 *** *** 1,19 ! Bug#: 1506 ! Product: XalanJ2 ! Version: 2.0.0 ! Platform: Sun ! OS/Version: Solaris ! Status: NEW ! Resoluti

Re: building xalan-c for tru64 unix

Hi Kari, If you get the latest sources from CVS, they will build cleanly. You might also just grap a copy of the tree from the build machine that I've been using. I've been debugging some problems and have been seeing some strange things. I'll send you an email off-list about them. Dave

RE: Crimson sneaking up on you...

Thank-you Scott! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, July 16, 2001 10:18 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Crimson sneaking up on you... Please be aware that the j2ee.jar that Sun has been shipping contains Crimson.

RE: Xalan 2.2 D7 increasing memory footprint?

>1. If you already have a DOM, passing DOM directly will be faster, >smaller memory footprint. >2. If you only have a Stream, using SAX parsing will win on both counts. That's what we intended, certainly.

Re: Xalan-C++ 1.2 (?)

Yes, look for a release in the first part of August. The source code in CVS is compatible with 1.5.1, so you can always build from CVS to get the latest code. Dave Holger Flörke

RE: Xalan 2.2 D7 increasing memory footprint?

Hehe.. I asked the same question a while ago. It seems to justify the way to FAQ on the website. Here is the answer I got: 1. If you already have a DOM, passing DOM directly will be faster, smaller memory footprint. 2. If you only have a Stream, using SAX parsing will win on both counts.

RE: Xalan 2.2 D7 increasing memory footprint?

Title: RE: Xalan 2.2 D7 increasing memory footprint? I'm curious: are either of these approaches actually faster than just feeding Xalan the already existent DOM tree and having it do its default DTM-wrapping approach? Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAI

cvs commit: xml-xalan/java/src/org/apache/xalan/lib/sql SQLDocument.java

sboag 01/07/24 06:01:50 Modified:java/src/org/apache/xalan/lib/sql SQLDocument.java Log: Don't set m_level anymore, as it looks like Joe commented out it's initialization. m_level is no longer called by Xalan, and the implementation can calculate it when it is called. Re

Re: Strange error message / Xalan-J 2.1.0

In another month or so we'll be switching over to a parser-generator approach (i.e. JavaCUP or JavaCC, YACC for the C++ version), so these bad diagnostics should go away. -scott

Re: Strange error message / Xalan-J 2.1.0

Hi Scott, thanks, that was the hint I needed, because I've already limited the error to one of the xsl templates used. After that I've tried to verify the transformation with Saxon and the error message was very explicit and even included the line number in the xsl file. It was a very trivial e

Re: Strange error message / Xalan-J 2.1.0

It's a bad error message for a problem in one of your xpaths. If you post the XSLT file, I can tell you what is the matter and how to fix it. -scott Jens

[GUMP] Xalan2 Smoketest Failure

This email is autogenerated from the output from: Buildfile: build.xml prepare: compile: [echo] compile ent

Re: Strange error message / Xalan-J 2.1.0

Hello Joseph, I've just tried Xalan 2.2.D7 and it's the same error message. I'm using Xalan from the command line with a batch file: --- set classpath=..\classes\xalan.jar;..\classes\xerces.jar;..\classes\bsf.jar;..\classes\xalanj1compat.jar; java org.apache.xalan.xslt.Process -

[Bug 1950] - Transformation encoding problem with DOMSource

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1950 *** shadow/1950 Sun Jul 22 01:34:10 2001 --- shadow/1950.tmp.15926 Tue Jul 24 01:32:14 2001 *** *** 234,237 for printing out your debugging information. Sending the actual code for this would be the most clear.