Re: [xsl] XSLT In the Build Process?

Subject: Re: [xsl] XSLT In the Build Process?
From: Mitch Amiano <mitch.amiano@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 15 May 2003 09:08:12 -0400
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.


Tom P

XSL-List info and archive:

XSL-List info and archive:

Current Thread