This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: [exsl] EXSLT 1.0 - Common, Sets and Math




>Congratulations again. Stuff steam engines - when I grow up I want to
>write proposals as clear as Jeni's.

Don't we all!

>
>Given that both sets of extension functions require the same
>infrastructure (xslt, exsl, and the com:eval function), and that you
>provide source for the functions in that infrastructure, I'd be inclined
>to put them in a single namespace, or at least a single proposal. OK,
>its inelegant, but as a transform author I'd rather not have to worry
>about whether adding a math function call to my set function calls will
>break the transform on someone's processor.
>

I like the split into functionality groups but think that EXSLT should
really be defined to include all the parts to avoid any confusion. On the
subject of what else Strings and Dates (as you mention) would appear to be
mandatory. The case for grouping is not so clear. I think this is something
that I would normally expect XSLT elements to handle (as apposed to XPath
functions), just a thought. This is obviously the subject of some XSLT 2.0
work so the working group members may be able to help out here.

One ability I would like is just to provide an implementation of the EXSLT
functions without supporting user-defined functions. I am not sure if this
really implies two different specs, or just one where there are two
conformance levels.

	EXSLT Functions (All functions supported by native implementation)
	EXSLT User Defined Function Support (Optional native implementations of
EXSLT functions)

Regards,
Kev.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]