xsl-list
[Top] [All Lists]

Re: [xsl] XSLT programs that blur the distinction between program and data?

2022-04-09 19:23:01
That is not blurring.
Many of you know me, I work for RenderX.
Take our VisualXSL product.
A GUI allow you to draw on a page, dropping XML elements, adding Xpath 
expressions and format.
In the end, you have an XML that *is* (according to VisualXSL) how you layout a 
document ... sections, page templates, blocks, tables, images, absolute 
positioned content, everthing down to fonts, inline content, etc.

The GUI creates an XML (you can save, edit with our product, do special 
things!).

Internally the XML is converted to an XSL that will process an XML (that you 
used for design to capture proper Xpaths).

You preview ... you have:

XML Design + RenderX VisualXSL Transform -> XSL (for XSL FO) + Sample XML _> 
RenderX -> PDF

And better, you can design "escapes/overrides" to the standard RenderX 
VisualXSL Transform.
Like I can add an attribute in design ... which in the Design XML may result in 
(no this in not everything, only representation)

<chunk custom_transform="My_personal_thing" 
xpath="link/to/what/I/am/processing"/>

And you override 

<template match="chunk/@transform="My_personal_thing">

And maybe it draws a graph or does something really special.

Does it fit either of the things you ask> Maybe, maybe not. Not sure ... but it 
is data (all in XML) that combines with (an extensible) XSL to make new XSL.

Kevin

-----Original Message-----
From: Norm Tovey-Walsh ndw(_at_)nwalsh(_dot_)com 
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 
Sent: Saturday, April 9, 2022 9:15 AM
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] XSLT programs that blur the distinction between program and 
data?

(1) An XSLT program may have some embedded XML that the program uses.
That embedded XML is both part of the program and it is data for the 
program; so it is both program and data. That is definitely blurring 
the distinction between program and data!

That doesn’t seem especially blurry to me. Most programs have some statically 
initialized data. I’m not sure my Java program with a map of arrays of maps is 
that different from an XSLT stylesheet with some embedded XML.

(2) An XSLT program can modify itself at runtime. [Is this possible?
Can one part of XSLT program treat another part of the program as 
data, modify it, and then continue running but with the modified 
program?]

That’s sort of going to depend on how you define your terms. An XSLT stylesheet 
doesn’t necessarily have access to its original XML form. It may have been 
compiled, for example. Excluding any magic that might be provided by extension 
functions, it has no facilities to modify its execution environment directly 
the way, for example, lisp systems often allow.

But if the processor implements fn:transform, then it can generate stylesheets 
on the fly to run. If it does have access to it’s original XML form, then it 
can use transformations of that form to generate the new transforms. 

I haven’t yet encountered a problem where that felt like the easiest way to 
solve it, but it could be done.

Is there a classic use case for (1)? That is, is there a classic use 
case for an XSLT program that uses embedded XML data?

Absolutely. The DocBook XSLT stylesheets, for example, embed the XML data for 
doing localization. (In fact, that data eventually got large enough and diverse 
enough that I pushed it back out into separate files, but it started off 
embedded. The stylesheet containing the embedding was, naturally, generated by 
processing a different stylesheet and the data. But that was a “preprocessor” 
step, not part of the user’s
runtime.)

Is there a classic use case for (2)? 

Almost certainly, but none spring immediately to my mind.

                                        Be seeing you,
                                          norm

--
Norman Tovey-Walsh <ndw(_at_)nwalsh(_dot_)com>
https://nwalsh.com/

Anger ventilated often hurries towards forgiveness; anger concealed 
often hardens into revenge.--Edward G. Bulwer-Lytton
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--


<Prev in Thread] Current Thread [Next in Thread>