Scott, Joe, and everyone -- This is a discussion that I've been having with Julian where he is a taking a somewhat novel approach. It requires some thought. I'd appreciate any input. Gary -------- Original Message -------- Subject: Re: [Bug 2307] - An extension function cannot return a NodeIterator. Date: Mon, 16 Jul 2001 10:25:02 -0700 From: Gary L Peskin <[EMAIL PROTECTED]> Organization: The Firstech Corporation To: Julian Birch <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Julian -- I think I understand what you're trying to accomplish. I need to think about it some more but I feel uncomfortable with using the xsl:for-each element in the way that you're trying to use it. Maybe it's causing this queasy feeling just because it's a new use -- I don't know. But it just seems wrong. It is a feature of the current implementation that we allow the use of a NodeIterator for this purpose. But we're really using NodeIterator to represent a node-set. The select attribute is supposed to return a node-set and your implementation really doesn't do this. Well, over time, it does. But not in the traditional sense. In theory, we should be able to examine all of the nodes in the node-set and then instantiate all of the children of xsl:for-each and we can't really do that with your implementation. For example, the xsl:for-each element allows an xsl:sort element as a child. How would that be handled in your implementation? Having said that, you might be able to get away with returning a DTMIterator instead of a NodeIterator. But this would be an artifact of the current implementation and would not be guaranteed to always work even if it worked today. I think you'd be much better off using an extension element for this sort of thing or even using a java program wrapper and drive the transformation from outside of XSLT from a java driver program which had a little loop in it and passed the next OrderFeed item into a transformation as a parameter. I'd really like to pass this email on to the list or at least to Scott and Joe who are the main implementers but I didn't want to do so without your permission. I think the input of others would be valuable here. You have an interesting approach and I think others should bounce it around. This is also somewhat related to the issue of pruning since I'm assuming that once you've processed an OrderFeed item, you won't need it anymore so that's something to think about as well. Gary Julian Birch wrote: > > Thanks for the reply. I'm glad it's now working. As I say, the getNodeList > was only a workaround anyway. > > Basically, what I'm trying to do is to use XSLT to perform data > standardization (quite like BizTalk if you're familiar with that). > > A use case is customer order processing. What I'd like to be able to do is > have a custom NodeIterator linked to an EDI link which converted the data to > XML which was then processed by the transformation. Obviously, I'm quite > likely to be using other extension functions and elements to actually > process it, but the ability to have XPath and XSL underpinning it is quite > attractive (we're currently using a custom architecture written in VB). The > thing is that I basically want the transformation to go on forever, so > nextNode blocks until it has received the next event. The pseudo code would > be: > > <xsl:for-each select="java:OrderFeed.new()"> > <ProcessOrder select="." /> > </xsl:for-each> > > So while the OrderFeed code is generic, the XSL file changes depending on > how the customer fills in the fields, what product codes he uses, and so on > and so forth. > > A related, simple case is processing a fixed-width text file. This is > actually where the 50,000 figure in bug 2308 comes from. When I process a > file with 50,000 rows in this way, it runs out of memory. I guess the > problem is that I'm treating all the data as transient, and the NodeSet is > storing it for later reference. > > Thanks for your time, > > Julian. > > > -----Original Message----- > > From: Gary L Peskin [mailto:[EMAIL PROTECTED]] > > Sent: Monday, July 16, 2001 4:03 PM > > To: Julian Birch > > Subject: Re: [Bug 2307] - An extension function cannot return a > > NodeIterator. > > > > > > Julian -- > > > > Can you post a use case in the form of XSLT and the java > > extension code > > that would illustrate what you have in mind. The modified version of > > the example that is in the bug report: > > > > <?xml version="1.0"?> > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > > xmlns:java="http://xml.apache.org/xslt/java"; > > version="1.0"> > > <xsl:template match="/"> > > <xsl:for-each select="java:Iterator.new()" /> > > </xsl:template> > > </xsl:stylesheet> > > > > works just fine in the current CVS build with for-each even though > > Iterator is not a ContextNodeList. > > > > Gary > > > > Julian Birch wrote: > > > > > > Okay, now I know what I'm trying to do is unusual, but it's > > actually a > > > fairly desirable thing to do. It opens up the possibility > > of processing > > > general event-driven data using XSL. > > > > > > I'll have to apologize in advance for not actually having a > > working dev > > > environment at the moment (licensing hell), but I do > > remember the details of > > > the problem. It didn't quite behave the way you describe > > in 2.1.0. I'm > > > afraid the absence of a dev env prevents me from checking > > it against the > > > latest code. > > > > > > The expression <xsl:for-each select="java:Iterator.new()" > > /> does not work > > > in 2.1.0 for reasons I never got to the bottom of. The > > getNodeList call was > > > actually a workaround to avoid the problem. > > > > > > The problem is that the code in ElemForEach presumes that > > any NodeIterator > > > implement ContextNodeList, which is why you end up writing > > a wrapper object > > > which takes a NodeIterator and returns a > > NodeIterator/ContextNodeList > > > object. I actually posted a workaround to the list which > > works by changing > > > the getNodeList function to invoke the wrapper class, which > > does work. > > > > > > In short, the extension mechanism in 2.1.0 was working > > fine, it's just that > > > ElemForEach was blowing up the code afterwards. The code > > in the latest dev > > > version was, I'm afraid, rather harder to understand. If > > what you're > > > describing in that actually I can junk all of the > > workarounds, this would be > > > great. > > > > > > Moving on from this, I'm not convinced that wrapping a > > NodeIterator in a > > > NodeSet is always the right thing to do, as the iterator > > interface was > > > specifically designed to cope with things the NodeSet > > interface cannot. In > > > fairness to the documentation, I'm pretty sure it always > > said this is what > > > happened. That said, it does seem a bit unfortunate that I > > can't assign a > > > NodeIterator to a variable without it being automatically > > converted. Is it > > > possible to disable this behaviour? > > > > > > Does this make any more sense? > > > > > > Thanks, > > > > > > Julian. > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > > Sent: Saturday, July 14, 2001 2:46 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [Bug 2307] - An extension function cannot return a > > > > NodeIterator. > > > > > > > > > > > > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2307 > > > > > > > > [EMAIL PROTECTED] changed: > > > > > > > > What |Old Value |New Value > > > > -------------------------------------------------------------- > > > > -------------- > > > > Status|NEW |RESOLVED > > > > Resolution| |INVALID > > > > > > > > > > > > > > > > ------- Additional Comments From [EMAIL PROTECTED] > > > > 2001-07-13 18:45 ------- > > > > I have reviewed the extension documentation and I see that > > > > handling of extension > > > > function return values is not covered. I will update the > > > > documentation shortly. > > > > Basically, a return value from an extension function is > > > > converted to an XSLT > > > > type, if possible. For example, a NodeIterator returned from > > > > an extension > > > > function is converted to an XSLT node-set. The documentation > > > > will contain the > > > > complete list of how various return types are handled. Thus, > > > > your expression > > > > java:getNodeList(java:Iterator.new()) > > > > is processed as follows: First the constructor for Iterator > > > > is called, which > > > > returns an Iterator. Since this implements the NodeIterator > > > > interface, it is > > > > converted to an XSLT node-set. Thus, the expression becomes > > > > java:getNodeList(an-xslt-node-set) > > > > The extension mechanism will look for the getNodeList() > > > > method on a Xalan class > > > > that represents an xslt node-set and that fails. The > > > > following (simpler) > > > > expression will accomplish exactly what you want: > > > > <xsl:for-each select="java:Iterator.new()" /> > > > > Please reply here or to the list if you have questions. > > > > Thanks, > > > > Gary > > > > > > > > > ============================================================== > > ============= > > > The information in this E-mail (which includes any files > > transmitted with > > > it), is confidential and may also be legally privileged. It > > is intended for > > > the addressee only. Access to this E-mail by anyone else is > > unauthorised. If > > > you have received it in error, please destroy any copies > > and delete it from > > > your system notifying the sender immediately. Any use, > > dissemination, > > > forwarding, printing or copying of this E-mail is prohibited. E-mail > > > communications are not secure and therefore Rolfe & Nolan > > does not accept > > > legal responsibility for the contents of this message. Any > > views or opinions > > > presented are solely those of the author and do not > > necessarily represent > > > those of Rolfe & Nolan. > > > > > ============================================================== > > ============= > > > =========================================================================== > The information in this E-mail (which includes any files transmitted with > it), is confidential and may also be legally privileged. It is intended for > the addressee only. Access to this E-mail by anyone else is unauthorised. If > you have received it in error, please destroy any copies and delete it from > your system notifying the sender immediately. Any use, dissemination, > forwarding, printing or copying of this E-mail is prohibited. E-mail > communications are not secure and therefore Rolfe & Nolan does not accept > legal responsibility for the contents of this message. Any views or opinions > presented are solely those of the author and do not necessarily represent > those of Rolfe & Nolan. > ===========================================================================
