> 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
>
> --
> --------------------------------------
> John Gentilin
> Eye Catching Solutions Inc.
> 18314 Carlwyn Drive
> Castro Valley CA 94546
>
> Contact Info
> [EMAIL PROTECTED]
> Ca Office 1-510-881-4821
> NJ Office 1-732-422-4917
--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917
