- 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
Jeni,
Do you think that it is a good practice to have a stand-alone XSLT module, the compile-time validity of which is dependent on global objects (such as xsl:variable s) in other modules? Could you provide an example when doing this is recommended or when it cannot be avoided?
It seems to be just common sense that the including module should depend on the ones it is including/importing — not the opposite.
Even when we have nice tools such as Oxygen, that help make such practice more bearable, does this make it a good practice?
Dimitre Novatchev