Re: [xsl] mode computation case

 Hi David,

In this typical case, the template with the xsl:choose is really a 
transformation entrypoint where parameters are validated and set, 
resources are checked and loaded, modes are determined and 
transformation is launch.
The main document has many different (nested) structures (e.g. building, 
pavilions, floors, departments, halls, rooms, closets) and they all have 
things, purposes, occupancy, heating, cooling, lighting, dimensions  
sections, objects, schedules, id, history, fabric, users, etc.  In other 
words, there is plenty of node matching to do for each entity type.  At 
the same time, for each entity type, there are a number of 
transformations that are required,  each processing different aspects of 
different node subsets.  Therefore, it seems that both are needed 
simultaneously, in parallel, node matching and mode-based processing.  
Your suggestion is good and should be applied when node matching is 
underused while modes are over used, which should probably be avoided 
anyway, especially as node matching is probably the best place to start. 
Unfortunately all is not always so simple.  Node matching and mode-based 
transformations are nicely complementary.  The implementors must have 
known that.  In practice I find that the support for node matching 
significantly exceeds support for modes and that balance could probably 
be relatively rectified, at least from a language user perspective.
That is certainly not to say that someone should favor modes over 
matching, on the contrary, but only that power usage should not be 
inhibited when required.
Regards,
Andre




> On 31/08/2010 20:02, ac wrote:
> > Anyway, these are suggestions, hopefully with some valid justification.
> >   For now I am handling it with clumsy and bulky redundant xsl:choose
> > statements, and it works. Mostly, it is not very elegant.
> whenever you find a template consists mostly of an xsl:choose then 
> usually the code can be simplified by modifying the match pattern so 
> the various branches are in different templates.
> In the example you show, that would mean matching on the @mode 
> parameter, and if that were done you could have different templates 
> for the different cases without needing different modes.
> > Not everything is "one shot", on the contrary.
>
> true but if the decision of which shot you are taking is taken 
> dynamically based on the input then usually template matching leads to 
> a more natural modelling of this than using modes (which are best when 
> there is a static choice within the stylesheet)
> David
>
>
> --~------------------------------------------------------------------
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
> or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
> --~--

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--