[Mitch Amiano]
However, I've found it is still difficult to get developers
to understand the semantics - this being perhaps the most
difficult part of transitioning and getting such a tool
adopted by others - and moreso if the XML encodes just a
characterization of the domain. If it attempts to be a
programming language, it seems to be easier to get
programmers to adopt it, but conversely less useful as a code
factoring tool.
Right, for myself, maybe I have been doing markup and transformation too
long, but for a lot of tasks I have to do, I automatically look to see
how I can easily define things like where to insert one data chunk into
another, or how to define customization differences, or where I can
result some existing data. Once I am clear on that, I look to see what
is the simplest xml driver file I can concoct that captures those
descriptions, then use that as input to an xslt transformation (or a
series of them). If things are simple enough, the xslt may not even
need any driver file.
Earlier, I would have thought in terms of the steps I needed to take to
get the result. I think that this evolution is very similar to the
progression from process-centric to data-centric view which been going
on for a decade or two. For many (most?) business-type tasks the main
work can be seen as transforming data from one form to another. Data
tends to be much more persistent than the procedures that created it,
and in those situations, data-centric is very valuable.
Have you seen Cleaveland's book "Program Generators with XML and Java"
(Prentice Hall PTR)?
Cheers,
Tom P
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list