Passin, Tom wrote:
[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.
So, you practice merciless refactoring on your XML, and make XML drivers for specific
transformation tasks? Is there some MVC-like pattern there, a "Source Transformer
Audience" as it were?
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.
The case I referred to was most definitely not a business information system.
Still, the developers immediately realized that a lot of the program code
already consisted of tables, encoded with long lists of #define manifest
constants, static arrays, and structures with bit fields. The ability to
readily match existing bit-field manipulation code through XML/XSLT was a major
selling point over the UML tool at the time. Sometimes it just takes a sidelong
look at a process to be able to identify a strong reusable information
component.
Have you seen Cleaveland's book "Program Generators with XML and Java"
(Prentice Hall PTR)?
No, I haven't, but I will. Thanks for the pointer.
Cheers,
Tom P
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list