Oops, it wasn't off list, but still a valid question. Now it's for anyone.
:-)
Hi Dimitre:
This is off list. I'm trying to reproduce/understand Gunther's problem,
and
am having difficulty. Doesn't this typing problem only exist if he is
either
working with extensions, as M Kay pointed out, or if he is importing a
schema using xsl:import-schema?
I'm only now starting to play around with XSLT 2.0, so this is a question
I
am posing to you , not an argument. Can you give me an example where
automatic casting takes place? I tried to create one multiplying two
values
and assumed, based on this thread, it would return an integer, but it
didn't
happen. Can you clarify the situation for my muddled mind?
thanks!
~ chuck white
The difficulties that even Jeni has prove Kurt's point.
My question is: Isn't there any way simply to nlock all these type
checking, please?
Don't understand me wrong -- I do not need to be convinced and
persuaded about the benefits of having a strong type checking system. I
admire Haskell, which has it.
But XSLT is *not* Haskell. Introducing such strong type checking into
XSLT make it almost impossible to work (if even Jeni has such
difficulties. then no mortal XSLT programmer would be able to do
anything at all), will decrease to zero its users population and will
change XSLT into something completely different, which is not XSLT any
more.
Do the authors of this beast really listen to what we are saying?
Do they respect the XSLT programmers' community?
Will XSLT 2.0 really be XSLT?
=====
Cheers,
Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list