- markup (52)
- xml (7)
- xslt (21)
- atom (8)
- overlapping markup (2)
- schema (9)
- creole (4)
- xforms (1)
- pipelines (7)
- coding (2)
- dtll (1)
- genealogy (3)
- gtd (1)
- hardware (1)
- legislation (1)
- ontologies (2)
- unicode (1)
- web (24)
- google (3)
- rdf (6)
- rest (3)
- wikis (1)
- work (1)
- xpath (1)
- xquery (1)
- xtech2008 (3)
- life (26)
- children (5)
- equality (6)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (7)
- xtech (6)
- blog (7)
- drupal (3)
Re: Big XSLT applications just got easier to manage
I’m inclined to agree that usually modules should be self-contained, and only depend on declarations from those it imports or includes. But there are situations where, for whatever reason, this is impractical.
For example, the developer of the stylesheets I’m working with at the moment defines all stylesheet parameters in the principal stylesheet module. One reason for this is that he’s using a tool to run the stylesheet which sets parameters by editing the DOM for the stylesheet document, but he also believes that that’s where stylesheet parameters belong. I have some sympathy with that view; you could define them twice, but there’s always the danger that the definitions will get out of sync.
I think that there are two main reasons for having several modules:
In the first case, you’ll typically import the module, and here I think it makes sense for the module to be self-contained.
In the second case, you’ll typically include the modules into the principal stylesheet module. Here, I think the argument for modules being self-contained is much weaker. You might split up your stylesheet based on the kind of elements it processes, or the kind of processing it does (for example, one module that does all the grouping work), or the namespace the element comes from, or the version it was introduced in, or for any number of other reasons.
It’s not hard to get into a situation where two modules each contain code that relies, in some way, on the other. For example, you might have one module that has code for processing tables, and another module that has code for processing sections and paragraphs. To do its job correctly, the module that processes tables needs to be able to handle paragraphs, but the module that processes sections and paragraphs needs to be able to handle tables (since tables can appear within sections). In that case, it seems wrong to impose an artificial precedence between the two modules.