John, I think we might have a disconnect here. Is the function returning a
node or a node-set?
If it is just returning a node, then the fix is easy, I think.
-scott
John Gentilin
<gentijo@eyecatch To: [EMAIL PROTECTED]
ing.com> cc: [EMAIL PROTECTED], xalan
<[EMAIL PROTECTED]>
Subject: Re: (SQL Extension / NPE
issue) Re: Help, waiting on an answer
03/28/2002 01:31
PM
Please respond to
xalan-dev
We could/should make FilterExprWalker more robust but I get the
feeling that if we tape off this leak, it will just spring up somewhere
else. Would one or more of the solutions below make more sense.
1) Create an object that will product an empty document statically ??
return this document instead of DTM.NULL.
2) Have the extension handler detect a return of DTM.NULL and
translate that to an empty document
3) Create a set of exception classes. If the base class is thrown then
translate that to an empty document. From there build a framework
that will allow the extension handler to return a special "Error"
document
using the exception framework to maintain a basic structure. i.e. Design
so that a fixed set of XPath statements will always work on an Extension
Error.
Previously my goal was to create an easy way to allow the stylesheet
designer
to detect a simple error. If I just threw an exception, that would
terminate the
transformation. My first version just returned a special "Error Document"
but
I was finding that a lot of time was used to execute two "apply-templates"
one
for the good document and one for the bad. Returning a NULL or empty
document
allowed the quicker <xsl:if test > to be used and it was far easier to
implement
contextual information in the error handling.
JohnG
[EMAIL PROTECTED] wrote:
> > It seems to me that returning DTM.NULL is a valid return
> > for an extension function, A) depending on the situation, you may not
be
> able to
> > construct an empty document, B) In the DOM spec,
> Element@getElementsByTagName
> > a return of null is valid if there are no matching elements. and C) the
> function
> > FilterExprWalker#isDocOrdred should really test of m_Expr != null
before
> > executing the method.
>
> There is no NULL in XPath, so dealing with null is somewhat problematic.
> For a nodeset, the equivalent of null is an empty nodeset. So a function
> that promises to return a node-set should return a node-set. A null is
> translated in XNull, and should really be dealt with like another
external
> opaque object, in that we don't know what to do with it in the context of
a
> node-set.
>
> I don't have any strong objection to making a filter expression handle a
> null return from an extension for the sake of robustness. But I don't
> think that it is a given.
>
> -scott
>
>
> John Gentilin
> <gentijo@eyecatch To:
[EMAIL PROTECTED], xalan <[EMAIL PROTECTED]>
> ing.com> cc: Scott Boag
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: (SQL Extension /
NPE issue) Re: Help, waiting on an answer
> 03/27/2002 08:05
> PM
>
>
>
> Scott,
>
> Glad to hear that you are felling better. I was assuming that SQL mods
> (besides the storm I started with the inclusion of 3rd party jars) just
> were
> not making it to the top of the list.
>
> The problem at hand.
>
> If the SQL Extension runs into a problem, it records the error and
returns
> DTM.NULL. This should allow you to test on the return nodeset then
> do error handling, in the stylesheet, based on the getError() Document
>
> for example:.
> <xsl:if test="not(sql:connect($db, $cinfo))" >
> <xsl:message>Error Connecting to the Database</xsl:message>
> <xsl:copy-of select="sql:getError($db)/ext-error" />
> </xsl:if>
>
> The worked fine on all the previous versions of Xalan until somewhere
> around
> D12/D14.
>
> The problem is that FilterExprWalker only checks for a null m_Expr in
some
> of
> the methods. I changed it so if m_Expr was null then execute
super.method
> ()
> since the default behavior of AxisWalker seems to be the correct
behavior.
>
> I had changed it originally but never checked it in because I did not get
> an
> solid answer for the question, "Can a Extension function return DTM.NULL
> or does it have to return an empty document. Someone commented that the
> spec is not clear in this area and since this was a behavioral type
change
> in an area that I have not spent tons of time in, I was waiting for a
> response
> before proceeding. It seems to me that returning DTM.NULL is a valid
return
> for an extension function, A) depending on the situation, you may not be
> able to
> construct an empty document, B) In the DOM spec,
> Element@getElementsByTagName
> a return of null is valid if there are no matching elements. and C) the
> function
> FilterExprWalker#isDocOrdred should really test of m_Expr != null before
> executing the method. My $.02.
>
> Regards
> John G
>
> [EMAIL PROTECTED] wrote:
>
> > Hi John. I was sick in January and part of February, and so missed
> *lots*
> > of mail. I'm still not caught up... I don't know if I ever will be.
> >
> > FilterExprWalker (which changed a lot with my last check-in, BTW) (and
> now
> > FilterExprIteratorSimple#executeFilterExpr) doesn't do any magic with
the
> > return from it's expression. So returning null would be a bad idea
> > (sorry). An extension meant to return a null nodeset should return an
> > empty DTMIterator or the like.
> >
> > I guess we could change this, so that null would be an acceptable
return
> > val. Do you think it should be changed?
> >
> > -scott
> >
> >
> > John Gentilin
> > <gentijo@eyecatch To: Scott Boag
> <[EMAIL PROTECTED]>
> > ing.com> cc:
> > Subject: Help, waiting
on
> an answer
> > 02/02/2002 03:46
> > PM
> >
> >
> >
> > Scott,
> >
> > In the last few weeks there were a few discussions on Iterators
> > and empty sets returned as null from extension functions. The only
> > thing I got feedback on was the legality of including InstantDB. Looks
> > like I created a little scuttle that got the lawyers all excited.
> > Anyway,
> > I would like to put the finishing touches on the SQL extensions but
> > I needed an answer on how empty sets were to be handled. It falls
> > into one of two categories. 1) Empty sets can not be returned as a
> > null. or 2) null is a valid return, and the Iterator in question needs
> > to test for null. I believe you were CC'ed on most conversations
> > and I read in the group that you were currently working on the
> > iterators so I though I would rattle your cage.
> >
> > Hope all is going well.
> >
> > Regards
> > JohnG
