Re: Need a helpful Xalan-guy for xml-security

Joseph Kesselman wrote: > > This dies out because I proposed an alternative solution (share the > XPathContext in the security code) and was told "Yeah, it looks like that > will work." Unless someone tells me there's still a problem, I'm presuming > this is closed. There still is a problem. In

DO NOT REPLY [Bug 5340] - xsltc does not generate correct ouput for namespace72

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-xalan/c/src/XMLSupport XMLParserLiaisonDefault.hpp

dbertoni01/12/10 13:47:44 Modified:c/src/XMLSupport XMLParserLiaisonDefault.hpp Log: Fixed problem with get accessors. Revision ChangesPath 1.14 +2 -2 xml-xalan/c/src/XMLSupport/XMLParserLiaisonDefault.hpp Index: XMLParserLiaisonDefault.hpp =

cvs commit: xml-xalan/c/src Makefile.in

dbertoni01/12/10 13:22:57 Modified:c/srcMakefile.in Log: Updated library version for Xerces. Revision ChangesPath 1.69 +2 -2 xml-xalan/c/src/Makefile.in Index: Makefile.in === RCS file

cvs commit: xml-xalan/test/java/src/org/apache/qetest/xsl CmdlineTestlet.java MSXSLTestlet.java XalanCTestlet.java StylesheetTestlet.java

curcuru 01/12/10 13:18:59 Modified:test/java/src/org/apache/qetest/xsl StylesheetTestlet.java Added: test/java/src/org/apache/qetest/xsl CmdlineTestlet.java MSXSLTestlet.java XalanCTestlet.java Log: Simplify StylesheetTestlet to use worker methods to

cvs commit: xml-xalan/test/java/src/org/apache/qetest ThreadedStreamReader.java

curcuru 01/12/10 13:18:05 Added: test/java/src/org/apache/qetest ThreadedStreamReader.java Log: Simplistic threaded stream reader for reading shelled processes' System.err/.out streams Revision ChangesPath 1.1 xml-xalan/test/java/src/org/apache/qetes

cvs commit: xml-xalan/java/src/org/apache/xml/dtm/ref DTMDefaultBase.java DTMManagerDefault.java

jkesselm01/12/10 12:55:50 Modified:java/src/org/apache/xml/dtm/ref DTMDefaultBase.java DTMManagerDefault.java Log: Efficiency improvement to the new DTM "overflow addressing" scheme. In some tests, this one alteration shaved about 30% off the runtime.

cvs commit: xml-xalan/java/src/org/apache/xalan/xslt Process.java

jkesselm01/12/10 12:49:47 Modified:java/src/org/apache/xalan/xslt Process.java Log: Removed the "magic" default which causes us to switch into incremental processing mode whenever we were writing to Standard Output (ie, -OUT had not been specified). If you want incremental proce

Re: Performance

Tom Bradford wrote: > > [EMAIL PROTECTED] wrote: > > Isn't this the problem of the XPath API not continuing the context from > > each API call? So we end up building a new DOM2DTM for every call??? > > Not sure if this is the case. From the looks of my code, we compile the > stringified form o

DO NOT REPLY [Bug 5346] New: - Stringified number with lots of places gets wrong value

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Performance

[EMAIL PROTECTED] wrote: > Isn't this the problem of the XPath API not continuing the context from > each API call? So we end up building a new DOM2DTM for every call??? Not sure if this is the case. From the looks of my code, we compile the stringified form of the expression for each document

Re: Need a helpful Xalan-guy for xml-security

--On Montag, 10. Dezember 2001 09:16 -0500 [EMAIL PROTECTED] wrote: > This dies out because I proposed an alternative solution (share the > XPathContext in the security code) and was told "Yeah, it looks like that > will work." Unless someone tells me there's still a problem, I'm presuming > thi

cvs commit: xml-xalan/java/src javadocOverview.html

dleslie 01/12/10 09:13:56 Modified:java/src javadocOverview.html Log: Removed version and author information. Version is in readme.xml and author is the Xalan developer community. Revision ChangesPath 1.2 +10 -14xml-xalan/java/src/javadocOverview.html

Re: State of XSLTC

Yes, that is what I was referring to. Thanks for fixing it. I'll give it another try soon. Chris Morten Jorgensen wrote: >Chris, > >Are you referring to the bug you filed? That bug was fixed today, >meaning that there was a bug in XSLTC that it is not there anymore. >So your configuration wa

RE: Performance

> [Scott Boag] > Hi guys. From what we can tell, at least in Tom's case, these > are cause by variables that create result tree fragments creating > a DTM each time. I'll pipe up here. We use the Xalan XPath facility standalone and had to roll back to 2.1.0 for performance reasons. That's ane

Re: State of XSLTC

Chris, Are you referring to the bug you filed? That bug was fixed today, meaning that there was a bug in XSLTC that it is not there anymore. So your configuration was correct and there is nothing you need to do other than download the latest CVS tree or wait for the next release of Xalan. Morten

cvs commit: xml-xalan/c/src/XSLT ElemNumber.cpp

dbertoni01/12/10 08:30:59 Modified:c/src/XSLT ElemNumber.cpp Log: Duh! Fixed bug in checking the length of the grouping separator. Revision ChangesPath 1.51 +1 -1 xml-xalan/c/src/XSLT/ElemNumber.cpp Index: ElemNumber.cpp

Re: State of XSLTC

I guess I must have had something configured wrong or something.  While looking for the source of the exception, I had stripped my testcase down to nothing more than a stylesheet that imports another stylesheet that declares a variable and I still got an exception.  If I did not import the other

Re: Performance

[EMAIL PROTECTED] wrote: > Hi guys. From what we can tell, at least in Tom's case, these are cause by > variables that create result tree fragments creating a DTM each time. > Since we do not specifically delete RTFs from the variable stack (which > would cause a penelty on all stack pops), RTF D

DO NOT REPLY [Bug 5340] New: - xsltc does not generate correct ouput for namespace72

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Sanity Check - DOMs and XSLT

Thanks David - It seems like a non-trivial problem. I'm looking forward to seeing how it all unravels (and helping out!). Our problem is one where we have no control over the input instances - they are b2b transactions so caching is certainly not an option. We are caching the compiled styleshe

DO NOT REPLY [Bug 5194] - xsltc tries to create a instruction with negative index

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/compiler/util MethodGenerator.java

morten 01/12/10 07:43:38 Modified:java/src/org/apache/xalan/xsltc/compiler/util MethodGenerator.java Log: Fix for use of XPath expressions in contexts where there is no 'current' node (ie. in top-level elements such as variables and attribute sets). PR:

RE: Sanity Check - DOMs and XSLT

All current XSLT processors require that the entire source tree be built for transformation. We'ed like to get to the point where we can build pieces of the tree, throw away pieces of the tree, or even not build the tree when we know the transformation can be streamed. However, that's something

DO NOT REPLY [Bug 5194] - xsltc tries to create a instruction with negative index

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

RE: Sanity Check - DOMs and XSLT

My understanding is that the SAXInputSource you describe is used to generate a XalaSourceTree for the entire document before a transformation can take place. So a DOM of sorts is created. I guess I mis-spoke. When I said DOM what I really meant was XalanSourceTree. The point being, the entire

[ERROR] Problems with sum()-Function and many decimal places

Hi *, we have a problem using sum()-function with numbers with more than 20 decimal places in Xalan-J-2.2.D14. Tracking down the problem I found that in class org.apache.xpath.objects.XStringForFSB the method toDouble() now uses Long to convert Strings to double (in the past the conversion was d

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/compiler Stylesheet.java

morten 01/12/10 05:55:59 Modified:java/src/org/apache/xalan/xsltc/compiler Stylesheet.java Log: Added a fix for global variables declared in included/imported stylesheets. PR: bugzilla 5327 Obtained from:n/a Submitted by: [EMAIL PROTECTED] Reviewed by: [E

DO NOT REPLY [Bug 5327] - XSLTC exception when imported stylesheet declares variable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: State of XSLTC

Bryan, > Does the TraX API still re-compile the translet every time? Not necessarily. In our TrAX implementation the TransformerFactory represents the compiler, the Templates object represents the compiled Java class (translet _class_) and the Transformer represents an instance of this class (tr

RE: State of XSLTC

Does the TraX API still re-compile the translet every time? -- bk >> -Original Message- >> From: Morten Jorgensen [mailto:[EMAIL PROTECTED]] >> Sent: Monday, December 10, 2001 1:36 AM >> To: [EMAIL PROTECTED]; Chris McCabe >> Subject: Re: State of XSLTC >> >> >> Chris, >> >> > Is XSL

DO NOT REPLY [Bug 5327] - XSLTC exception when imported stylesheet declares variable

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/runtime BasisLibrary.java

morten 01/12/10 05:08:09 Modified:java/src/org/apache/xalan/xsltc/runtime BasisLibrary.java Log: Added another fix to properly convert ver small floating point numbers to strings. PR: bugzilla 4199 Obtained from:n/a Submitted by: [EMAIL PROTECTED] Review

DO NOT REPLY [Bug 4199] - xsltc fails conf tests string134 and string135 converting string to real number

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/compiler xpath.cup

morten 01/12/10 04:53:07 Modified:java/src/org/apache/xalan/xsltc/compiler xpath.cup Log: A fix for a bug in the XPath parser. The parser would choke on some XPath expressions that contained references to element names that were identical to axis names. PR: bugzilla

cvs commit: xml-xalan/java/src/org/apache/xalan/xsltc/runtime AbstractTranslet.java

morten 01/12/10 02:15:12 Modified:java/src/org/apache/xalan/xsltc/runtime AbstractTranslet.java Log: A fix for global parameters whose names contain dots or dashes. PR: bugzilla 5328 Obtained from:n/a Submitted by: [EMAIL PROTECTED]

DO NOT REPLY [Bug 5328] - [XSLTC] xsl:param with dash in name not working

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

DO NOT REPLY [Bug 5336] New: - javax.xml.transform.TransformerFactoryConfigurationError

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: State of XSLTC

Chris, > Is XSLTC anywhere near a state of being generally useful? It is indeed. > I was under the impression that it mostly works, but it seems > that very basic stuff does not work. I am not sure what you are referring to. XSLTC conforms to the XSLT 1.0 and XPath 1.0 specs. There are about 1

DO NOT REPLY [Bug 5332] - [XSLTC] problem with XPath expression "namespace"

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Need a helpful Xalan-guy for xml-security

Hi Sam, hi Joe, thanks for re-starting this thread again. From the point of view of the xml-security project, I need two changes. 1. The org.apache.xpath.XPathContext#m_dtmManager variable has to be changed from private to protected. I extend the XPathContext and this would give me the necess