Re: Basic program structures in XSLT (was: Re: [xml-dev] Data-driven application --> the data is essentially "machine code" to the application, right?)

On Fri, Dec 9, 2022 at 5:28 PM Dimitre Novatchev <[email protected]>
wrote:

> 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.
>
> Indeed.  For me, one of the most powerful aspects of XSLt was (back when I
was using it extensively) the ability to combine multiple documents and to
use one input to dynamically modify the other.


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