You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Elliotte Rusty Harold <el...@metalab.unc.edu> on 2002/03/27 01:42:31 UTC

Extension function return types

The documentation on extension functions at 
http://xml.apache.org/xalan-j/extensions.html seems to be incomplete 
inregard to return types from extension functions written in Java. In 
particular:

1. It does not specify what happens when an extension function returns a 
primitive type such as double or int. The documentation implies that any 
of the types not listed in the Return values table will be a "Non-XSLT 
Type ". However, in my tests returning a primitive data type does seem 
to work.

2. (possibly related) What is the result of taking the value of a 
Non-XSLT Type with xsl:value-of? My tests suggest that it is calling the 
toString() method of the Java object, but I don't see this doucmented 
anywhere.

-- 
+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+ 
|           The XML Bible, 2nd Edition (IDG Books, 2001)             |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:   http://www.cafeaulait.org/     | 
|  Read Cafe con Leche for XML News:  http://www.cafeconleche.org/   |
+----------------------------------+---------------------------------+




RE: Extension function return types

Posted by Gary L Peskin <ga...@firstech.com>.
Elliotte --

Please see my comments below.

Gary

> -----Original Message-----
> From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu] 
> Sent: Tuesday, March 26, 2002 7:34 PM
> To: xalan-j-users@xml.apache.org
> Subject: Re: Extension function return types
> 
> 
> At 7:04 PM -0800 3/26/02, Frank E. Weiss wrote:
> <snip>
> 
> >I'm not completely certain, but the XPath number type is double. So 
> >int should convert to double. You could also refer
> >to XPath's number() function.
> 
> That would make sense, and it does seem to be what happens. However, 
> I don't see anything in the Xalan documentation that says this is 
> what's supposed to happen. Furthermore, some parts of the Xalan 
> documentation imply that this does not happen because they 
> exclusively discuss object types and talk about operations Java 
> performs on return types which would only be valid on object types.
> 
> I'm specifically worried about "The Xalan-Java extension mechanism 
> examines the class of the value returned from a function and converts 
> the value into an XSLT type according to the following table:... Note 
> that the above test is applied using instanceof so that any 
> subclasses of the classes listed above will be treated the same as 
> the listed superclass." Again, what happens if the Java method 
> returns a non-Object? You can't use instanceof. This procedure can't 
> work. Since I do see primitive return types working, then there's got 
> to be something more happening than the documentation covers.

XalanJ invokes an extension function method using the invoke(..) method
of the Method class.  The invoke() method returns an Object.  The
javadoc for this method states "If the method completes normally, the
value it returns is returned to the caller of invoke; if the value has a
primitive type, it is first appropriately wrapped in an object. If the
underlying method return type is void, the invocation returns null."
This is exactly what XalanJ does.

I agree that the documentation should be clearer and should indicate
that this is what happens.  Unfortunately, I'll be unable to fix this
myself for a few weeks.  I would propose adding an additional "Note"
after the existing "Note" in the "Return values" section that states:

"The return value from a java extension function is always an object.
If the java extension function returns a primitive type, it is first
appropriately wrapped in an object.  If the java extension function
specifies a return type of void, the function will return null."

Would you please open a Bugzilla report asking that this documentation
be changed?  If you have an idea for clearer wording, could you please
add that in to your bug report?

> 
> >>  2. (possibly related) What is the result of taking the value of a
> >>  Non-XSLT Type with xsl:value-of? My tests suggest that it 
> is calling the
> >>  toString() method of the Java object, but I don't see 
> this doucmented
> >>  anywhere.
> >
> >This is one of the most common problems for XSL/XSLT stylesheet 
> >writers. The xsl:value-of element always converts to
> >string, compare it with xsl:copy-of. The W3C docs cover this (but 
> >admittedly, sometimes these little facts are easily
> >skimmed over, due to the W3C writers' studied terseness.)
> 
> Yes, but how does it convert it to a string? Does it call back to a 
> toString() method? Does it do something else? Do the details depend 
> on what kind of object it is? And what happens when it's a Java 
> primitive type like long so there's not toString() method to call 
> back to? The documentation just glosses over these points.
> 
> I've done experiments so I think I know what is happening, and I 
> could look at the source code to see what's going on under the hood. 
> However, that wouldn't give me any guarantees everything I think I 
> know isn't going to change in 2.3.2. Past experience makes me 
> extremely chary of relying on the documented parts of the Xalan API. 
> Relying on the undocumented parts really scares me.

It does appear that there is a callback to the toString() method unless
the Non-XSLT type is null is which case the empty string ("") is
returned.  I don't believe that there is a way to get a Non-XSLT type
that is a primitive type.  As far as I know the only way to get a
Non-XSLT type is to return it from an extension function and, as we saw
above, this is wrapped in an appropriate object.  So a long returned
from an extension function would become a Long which does have a
toString() method, like any object.

Could you also please open a Bugzilla entry on this?  Please post to
that entry where you think that this information should go in the
documentation.  I do think that we should maybe have a separate section
in the documentation where we explain these sorts of implementation
decisions.  OTOH, some may think that this is just too detailed and
might limit future flexibility and that anyone wanting to know this
stuff should refer to the code itself.

Thoughts?


Re: Extension function return types

Posted by Elliotte Rusty Harold <el...@metalab.unc.edu>.
At 7:04 PM -0800 3/26/02, Frank E. Weiss wrote:


>I hope you haven't overlooked the XSLT documentation, 
>http://www.w3.org/TR/xslt and http://www.w3.org/TR/xpath, which,
>if I'm not mistaken, is more definitive than the Xalan-J documentation.
>

That only defines how extension function names are recognized. It 
doesn't say anything about how types are mapped to various 
programming languages. The XSLT 1.1 draft started down this road and 
got slammed for it. So we're back to the status quo with XSLT 1.0: 
everything except name recognition is implementation dependent.


>I'm not completely certain, but the XPath number type is double. So 
>int should convert to double. You could also refer
>to XPath's number() function.

That would make sense, and it does seem to be what happens. However, 
I don't see anything in the Xalan documentation that says this is 
what's supposed to happen. Furthermore, some parts of the Xalan 
documentation imply that this does not happen because they 
exclusively discuss object types and talk about operations Java 
performs on return types which would only be valid on object types.

I'm specifically worried about "The Xalan-Java extension mechanism 
examines the class of the value returned from a function and converts 
the value into an XSLT type according to the following table:... Note 
that the above test is applied using instanceof so that any 
subclasses of the classes listed above will be treated the same as 
the listed superclass." Again, what happens if the Java method 
returns a non-Object? You can't use instanceof. This procedure can't 
work. Since I do see primitive return types working, then there's got 
to be something more happening than the documentation covers.

>>  2. (possibly related) What is the result of taking the value of a
>>  Non-XSLT Type with xsl:value-of? My tests suggest that it is calling the
>>  toString() method of the Java object, but I don't see this doucmented
>>  anywhere.
>
>This is one of the most common problems for XSL/XSLT stylesheet 
>writers. The xsl:value-of element always converts to
>string, compare it with xsl:copy-of. The W3C docs cover this (but 
>admittedly, sometimes these little facts are easily
>skimmed over, due to the W3C writers' studied terseness.)

Yes, but how does it convert it to a string? Does it call back to a 
toString() method? Does it do something else? Do the details depend 
on what kind of object it is? And what happens when it's a Java 
primitive type like long so there's not toString() method to call 
back to? The documentation just glosses over these points.

I've done experiments so I think I know what is happening, and I 
could look at the source code to see what's going on under the hood. 
However, that wouldn't give me any guarantees everything I think I 
know isn't going to change in 2.3.2. Past experience makes me 
extremely chary of relying on the documented parts of the Xalan API. 
Relying on the undocumented parts really scares me.
-- 

+-----------------------+------------------------+-------------------+
| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
+-----------------------+------------------------+-------------------+
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
+----------------------------------+---------------------------------+
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |
+----------------------------------+---------------------------------+

Re: Extension function return types

Posted by "Frank E. Weiss" <fr...@well.com>.
Elliotte Rusty Harold wrote:

> The documentation on extension functions at
> http://xml.apache.org/xalan-j/extensions.html seems to be incomplete
> inregard to return types from extension functions written in Java. In
> particular:

I hope you haven't overlooked the XSLT documentation, http://www.w3.org/TR/xslt and http://www.w3.org/TR/xpath, which,
if I'm not mistaken, is more definitive than the Xalan-J documentation.

> 1. It does not specify what happens when an extension function returns a
> primitive type such as double or int. The documentation implies that any
> of the types not listed in the Return values table will be a "Non-XSLT
> Type ". However, in my tests returning a primitive data type does seem
> to work.

I'm not completely certain, but the XPath number type is double. So int should convert to double. You could also refer
to XPath's number() function.

> 2. (possibly related) What is the result of taking the value of a
> Non-XSLT Type with xsl:value-of? My tests suggest that it is calling the
> toString() method of the Java object, but I don't see this doucmented
> anywhere.

This is one of the most common problems for XSL/XSLT stylesheet writers. The xsl:value-of element always converts to
string, compare it with xsl:copy-of. The W3C docs cover this (but admittedly, sometimes these little facts are easily
skimmed over, due to the W3C writers' studied terseness.)