[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
At 04:37 PM 8/24/2005, Dimitre wrote:
I admit this may be the case and probably is, even though it may be too early to have seen it much in action. Incoming reports are encouraging.
Of course, some of us have learned (or may just be temperamentally inclined) to be obsessive about our types anyway, always asking "what type is that? how will it coerce to that other type?" This level of attention to detail may be called for to write robust code in XSLT 1.0 (to say nothing of conciseness and elegance).
To be sure, others could reasonably assert that this only shows that some people are willing to accept the headaches (and sometimes, surprises) to which you allude, and live with them ... which doesn't make them a good thing. (Hm: maybe we need *both* static typing, and such obsessiveness, each reinforcing the other. I just wish the set of types were smaller.)
-- Assuming they understood or at least accepted that reliability as an established fact. As Mike said, these assessments are often made subjectively, and the argument "it's easier to write good reliable code in a language with static typing" isn't going to go over very well in very many elevator conversations. It's just too deep.
(What's static typing again? A keyboard that doesn't require you to move your fingers?)
Yes, and I hope we get them -- the specification will benefit from the attention just as we benefit from the tools.
Re: [xsl] How to get UTC displayed on XSLT
Subject: Re: [xsl] How to get UTC displayed on XSLT From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Wed, 24 Aug 2005 16:48:14 -0400 |
At 04:37 PM 8/24/2005, Dimitre wrote:
What remains to be added is one very important advantage of XSLT 2.0.
Static typing makes XSLT 2.0 a considerably more safe (reliable) programming language. Many errors that otherwise would go unnoticed and could produce havoc at unspecified future time are reported by an XSLT 2.0 processor at compilation time.
This significantly decreases the total time for development and minimizes headaches and surprises.
I admit this may be the case and probably is, even though it may be too early to have seen it much in action. Incoming reports are encouraging.
Of course, some of us have learned (or may just be temperamentally inclined) to be obsessive about our types anyway, always asking "what type is that? how will it coerce to that other type?" This level of attention to detail may be called for to write robust code in XSLT 1.0 (to say nothing of conciseness and elegance).
To be sure, others could reasonably assert that this only shows that some people are willing to accept the headaches (and sometimes, surprises) to which you allude, and live with them ... which doesn't make them a good thing. (Hm: maybe we need *both* static typing, and such obsessiveness, each reinforcing the other. I just wish the set of types were smaller.)
Therefore, if a developer or an organisation have a choice, it is very probably they would choose XSLT 2.0 over XSLT 1.0 due to the increased safety and reliability of the final deliverables.
-- Assuming they understood or at least accepted that reliability as an established fact. As Mike said, these assessments are often made subjectively, and the argument "it's easier to write good reliable code in a language with static typing" isn't going to go over very well in very many elevator conversations. It's just too deep.
(What's static typing again? A keyboard that doesn't require you to move your fingers?)
A developer, of course, would have many other additional reasons (such as overall elegance, more consistency, brevity of expression, ..., etc) to prefer XSLT 2.0. Many developers have expressed their strong wishes to have an XSLT 2.0 processor from their preferred vendor.
Yes, and I hope we get them -- the specification will benefit from the attention just as we benefit from the tools.
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] How to get UTC displayed , Dimitre Novatchev | Thread | Re: [xsl] How to get UTC displayed , David Carlisle |
Re: [xsl] 1.0 and 2.0 and suitabili, Dimitre Novatchev | Date | Re: [xsl] 1.0 and 2.0 and suitabili, Wendell Piez |
Month |