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.)
>
>