tag:blogger.com,1999:blog-33074681.post115693307120378741..comments2007-11-04T14:28:05.491+01:00Florent Georgeshttp://www.blogger.com/profile/18018229770454570703noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-33074681.post-1158887191336125182006-09-22T03:06:00.000+02:002006-09-22T03:06:00.000+02:00Hi Dimitre<BR/><BR/> Thanks for your comment.<BR/><BR/> I agree the name of f:copy-with-type-1() is not the better name I ever found for a function. I named it in part after the ELisp <I>de-facto</I> convention for utility routines, and in part because it is the implementation of f:copy-with-type() for a single item as argument.<BR/><BR/> The order of the xsl:when clauses is clearly important. They are generated by data/func-copy-make-whens.xsl from data/xs-simple-types.xml (note the hierarchical relation between the types), and you can see the result in data/func-copy-whens.xml. I guess (I hope) this kind of relation could be infered from XML Schemas, but I didn't write such a generator yet.<BR/><BR/> About your second comment, I'm a little bit septic. The first point is that the result of calling a function could be verry different if the type of the argument is not preserved. It is more true for nodes, but it is still true for atomic items.<BR/><BR/> The second point is that the user will choose if he needs an exact type-preserving copy for user-defined simple types. If he doesn't, he'll just use the builtin implementation (the only one we can provide, only aware about the standard simple types). If he does, he'll can provide a custom resolving function (maybe generated).<BR/><BR/> The user will can register a default resolving function, but also provide different resolving functions at several call points of f:copy-with-type(), as an additional argument.<BR/><BR/> But all of this still needs to be proved by an implementation...<BR/><BR/> Thanks a lot. Regards,<BR/><BR/>--drkmFlorent Georgeshttp://www.blogger.com/profile/18018229770454570703noreply@blogger.comtag:blogger.com,1999:blog-33074681.post-1158875312117797622006-09-21T23:48:00.000+02:002006-09-21T23:48:00.000+02:00Hi Florent,<BR/><BR/>This exploration of type-preserving copy is very useful.<BR/><BR/>I have just the following comments:<BR/><BR/>1. In the code of f:copy-with-type-1() (maybe you can think of a name that is more easy to remember?) the order of the &lt;xsl:when> instructions is very important.<BR/><BR/>The only correct ordering is from more specific (derived) types to their base types.<BR/><BR/>Any violation of this ordering will produce unwanted results, for example an xs:integer could be typed as xs:decimal.<BR/><BR/>2. My second comment is about the user-defined simple types.<BR/><BR/>Maybe we are paying too much attention to this problem. Instead of trying to correctly discover such user-defined types, it would be better to impose the restriction that simple-typed arguments of first-class functions must be only of the standard simple types.<BR/><BR/>THis is not a big restriction. If a user-defined type was really required for an argument, the function code can immediately apply the necessary constructor to the standard-typed argument and thus obtain the user-defined typed value.<BR/><BR/>THank you for your work in this area. It has been pleasure to read.<BR/><BR/>Cheers,<BR/>Dimitre NovatchevAnonymousnoreply@blogger.com