Santiago proposes: >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....Interpretive Xalan can just ignore the XSLTC >[namespace]extension.
I get a little nervous about splintering the extension namespace after we cleaned up all the old namespaces. We should discuss putting this attribute in the Xalan namespace. The interpretive side could ignore it or obey it. (I'm leaning toward ignore.) The same stylesheet would be used for both. For harmony with the XSLT 2.0 standard, I suggest that we call it xalan:as. (In XSLT 2.0, xsl:variable has an "as" attribute which can be set to any sequence type, including types from your own schema if you "imported" the schema.) The other naming issue is how to name the values. The "XSLT built-in types" may need to be placed in the Xalan namespace. (XSLT 2.0 will put most built-in types into the Schema namespace.) The Java class types might prefer a dotted notation, which has some interesting interplay with QNames. The names should be readable and amenable to error-checking. Anyone else have some ideas or thoughts? .................David Marston
