RE: [xsl] XSLT In the Build Process?

Subject: RE: [xsl] XSLT In the Build Process?
From: "Jim Fuller" <jim.fuller@xxxxxxxxxxxxxxxxxx>
Date: Tue, 13 May 2003 10:18:39 +0100
I've been doing this type of thing for awhile now, undoubtably my first attempts were modified as I gained experience ....but whenever the term ' framework' creeps into such code generation techniques, I found a couple of rules of thumb applied
 
- identifying data sinks and sources is important to identifying processing requirements for the build process e.g. can you control the process flow completely within XSLT or will the use of xsl:import / xsl:include, or some sort of template hiearchy, et al become too cumbersome as your 'framework' evolves...leading me to my cryptic Ant email. To a certain degree some of the new bits of functionality contained in XSLT 2.0 will undoubtably lead to greater ab/use of it in these types of situations....such things happen when there is a distinct lack of 'xml pipeline' type 
processing adoption.
 
- a good document centric definition of your data will tend to survive the stages of evolution your framework will process through ( messy kitchen, white box, black box... )..though others may argue against this point.... document centric data tend to stand alone and makes the architecture that grows around the processing of such data more forgiving.
 
- XSLT is undoubtably useful in performing these pre-compile time ( macro type ) tasks; and I have used it at length in generating c++ code. I found that the greatest benefit was the stable 'specification' of the data bits that fell out of my logic over time..e.g. ultimately this resulted in standard bits of UML markup being pushed back to my model, strange because I was used to generating UML then coding, but I now firmly believe there exists a mystery step between modelling an application and writing it; we tend to write a lot of prototypes here, ultimately getting feedback back into your model is much easier if you are squeezing out xml data ( if your model is specified in xml ), and keeps your software model equivelent to code ! important if you are to use your model throughout the entire development lifecycle of software. How many of us have initially modelled software with all good intentions, only to update the UML at the very end of the project for documentation purposes !
 
- XSLT is powerful, but so are regular expressions in some tricky code generation situations...if you use something like ant as a pipeline processor, then this allows you to use the benefits of XSLT at arms length whilst being able to integrate other processes. 
 
- frameworks with XSLT are sprouting up aplenty, make sure you decide if your framework is a developer tool for generating code ( to be thrown away after code is generated, read no dependancies ) or it is part of a software/application framework which embodies some sort of code reuse / inheritance / customisation mechanism. You will find these 2 requirements will tend to converge, and there are some rather non-intuitive pitfalls where the twain meet.
 
just my 2 p.
 
cheers, Jim Fuller

ps: sorry if this is a double post....
------------------------------------------------------------
Jim Fuller
SLG Technical Manager
jim.fuller@xxxxxxxxxxxxxxxxxx
www.stuartlawrence.com

-----Original Message-----
From: Passin, Tom [mailto:tpassin@xxxxxxxxxxxx]
Sent: 12 May 2003 15:36
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: RE: [xsl] XSLT In the Build Process?


[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

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient please contact the sender immediately. Any disclosure, copying, distribution or any other use of this communication is strictly prohibitedand may be unlawful. Stuart Lawrence Marketing Communications Limited reserves the right to monitor and intercept communications for unlawful business purposes.

This also confirms that this message has been swept for viruses, although Stuart Lawrence Marketing Communications Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or contents.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread