Re: Basic program structures in XSLT (was: Re: [xml-dev] Data-driven application --> the data is essentially "machine code" to the application, right?)
Dimitre Novatchev <[email protected]> Fri, 9 Dec 2022 15:27:53 -0800
| Newsgroups | gmane.text.xml.devel |
|---|---|
| Message-ID | <CAK4KnZdw2ymxSk+-toQZU1UJnVbhva6=Lqdakxy4EkptiLvYHw@mail.gmail.com> |
Sometimes the structure of the wanted result(s) is so different from the structure of the input(s), that a chain of successive (multi-pass) transformations that use intermediary trees/data-formats may be needed. Thanks, Dimitre On Fri, Dec 9, 2022 at 1:43 PM Jean Kaplansky <[email protected]> wrote: > On Fri, Dec 9, 2022 at 3:46 PM G. Ken Holman < > [email protected]> wrote: > >> At 2022-12-08 10:52 -0700, C. M. Sperberg-McQueen wrote: >> >are there analogous basic >> >principles for program design which can be used to guide construction of >> >a transformation in XSLT? >> >> The focus/orientation of program design from the programmer's >> perspective is the document order of the output, which is totally >> independent of the document order of the input. >> > > JLK: This is the most succinct description I've seen in this conversation, > although others have mentioned it in addition to other concepts. XSLT > enables rearranging content for context-specific purposes without > rearranging the source. > > >> (though being the same helps) >> >> (many students would ask me about "going back" and "fixing" or >> "adding to" content that already has been processed) >> >> That and the already mentioned distinction of push and pull comprise >> most of the introduction lecture in my XSLT class. >> >> JLK - I've seen this described elsewhere as the difference between > imperative and declarative. A long time ago, in an Arbortext far away, we > talked about "Declarative vs. Procedural." Ian Williams boiled that down to > a sentence: "an XSLT programmer does not define a sequence of actions, but > specifies a number of rules that. the result should satisfy." > > (I think a lot about this stuff these days. I have direct reports in India > who are still learning. I need to find the easiest way to state stuff that > often gets stated in any number of ways [see note about Arbortext above] > over time.) > >