Cart
[Home] [By Thread] [By Date] [Recent Entries]
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.
|
