Hi, Santiago
Thanks for your suggestion. Your solution might be easier to implement. We
need to know how the users like the XSLTC specific extension attributes. If
they do not mind writing XSLTC specific code in the stylesheet, we can use
the extension attribute solution. If supporting the same syntax in Xalan
and XSLTC is more important, then my old solution might be better. The
runtime method resolving solution also has a benefit that a parameter can
bind to different types at runtime. If the users value ease of use and
extensibility as more important, this might be a better solution.
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: [EMAIL PROTECTED]
Santiago
Pericas-Geertsen To: Morris
Kwan/Toronto/[EMAIL PROTECTED]
<Santiago.PericasGeerts cc: [EMAIL
PROTECTED]
[EMAIL PROTECTED]> Subject: Re: XSLTC
Extensions
09/02/2003 05:40 PM
Morris Kwan wrote:
>Supporting this paramter passing scenario requires a runtime method
>resolving feature in XSLTC. You can also see this note
>(http://marc.theaimsgroup.com/?l=xalan-dev&m=106250879605900&w=2) for
>information.
>
An alternative would be to add an extension attribute to xsl:param.
Something like xsltc:type that a user can set to the runtime type of the
parameter. This type would be either an XSLT built-in type or a Java
class type. The advantage of this approach is that there's no need for
reflection and dynamic lookups. It should be relatively simple to
implement too.
There would be a problem if a stylesheet uses the same parameter to pass
objects of different types, but in that case, one could argue that the
stylesheet is a bit hacky anyways. Interpretive Xalan can just ignore
the XSLTC extension.
-- Santiago