[
Lists Home |
Date Index |
Thread Index
]
> It is exactly this kind of reasoning by the designers of W3C XML technologies that is the bane of XML.
>
> XML is being used by the "man on the street" developer not just the MIT graduates who cut their teeth on Scheme and Haskell. So designing XML technologies as if they are expected to only be used by talented programmers with impressive educational pedigrees is probably not the wisest policy.
SQL also involves a significant departure from imperative programming techniques, and yet it is a success. I don't buy for a minute the idea that declarative or functional programming are outside the capacity of the mass of programmers, and I tend to consider it a tad bit elitist to espouse this idea.
> I am actually curious as to how you've convinced people that the fact that XSLT doesn't have variables [or semi-decent text manipulation facilities] and it takes one a two page stylesheet to simulate a for loop will give them as you put it " gain [that] is worth the pain" ?
In my experience, people are won over to XSLT once they have a chance to get some perspective, and this usually doesn't take long at all. I have had much occasion working with developers who curse and splutter all the time at all the little tripping points of XSLT that Mike Kay points out. But at least twice, I remember a developer saying, after a few days of this, something to the effect of "wow, XSLT is certainly a different way of thinking, but I must say that I accomplished my XML processing task using XSLT in a fraction of the time it took for me to do the same with DOM and Java". I have also heard variations of this (i.e. APIs other than DOM and languages other than Java) several times.
In the end, productivity is what makes people accept XSLT.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 720 320 2046
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Boulder, CO 80301-2537, USA
XML strategy, XML tools (http://4Suite.org), knowledge management
|
