Re: XSLTC Extensions

[Santiago Pericas-Geertsen]

[EMAIL PROTECTED] wrote: 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.  Yes, I'd be nice to keep the extension namespaces to a minimum as you say. 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.)  Agree. Also, the semantics of the possible type conversions will have to be defined as in 2.0, with the addition of the Java types (part of this is already implemented in XSLTC, I think). 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?  Yes, that's why I did not propose to xs:QName as the type of the attribute :-) I suppose one can replace "." by some other sensible char, but I don't really have a good suggestion at the moment. -- Santiago