I'm glad you found my input to the conversation useful, Roger.

But please note that in addition to the centralized core behaviour with onion skins is my observation that data-driven outputs are best addressed using declarative methods, while typical imperative methods impose a program-driven approach without a lot of, as you say, conditionals, branching logic, etc. That on its own justifies a declarative approach, not considering the behaviour modification you focused on.

Perhaps closer to home, allow me to describe another project I created, back in 2004, with the concept of a core behaviour with onion-skin layers.

Post-9/11 investigations included a joint Congressional inquiry and the independent 9/11 Commission, whose July 2004 report proposed sweeping Intelligence Community changes. President George W. Bush signed four Executive Orders in August 2004 that strengthened and reformed the Intelligence Community.

Already by then, the Intelligence Community Metadata Working Group (ICMWG) was formed in 2001 to establish standards for IC information, especially in HTML and XML. They worked on creating an XSD for US intelligence documents. I gather it was not quickly being picked up because of legacy collection and publishing environments.

As I heard tell, what triggered concerns requiring such 2004 Executive Order reforms was the assessment that each branch of intelligence gathering had difficulties ingesting and comprehending reports from other agencies that did not have their own historical cover pages, tables of content, appearance, geometry, fonts, etc. Metadata was inconsistent. Documents didn't look the same (apparently important to the higher-ups).

In particular, Executive Order 13356 "Strengthening the Sharing of Terrorism Information To Protect Americans" https://www.presidency.ucsb.edu/documents/executive-order-13356-strengthening-the-sharing-terrorism-information-protect-americans
emphasized the need for successful interchange ... it gives highest priority in part to:

>(ii) the interchange of terrorism information among agencies, (iii) the interchange of terrorism information between agencies and appropriate authorities of States and local governments

So ... how to get all the organizations to adopt the ICMWG XML but still be able to consume not only their own documents in their formats, but also the documents of others in their own format rather than the original. Likewise, the other organization would see their documents following the other conventions.

I was brought in as the XML Technology Lead (and, being Canadian, the only foreign national on the project team) and created a non-classified publishing system for use in classified environments. The system accommodates the one XML vocabulary for intelligence documents and equips the different groups (e.g. CENTCOM, STRATCOM, USF South Korea, Coast Guard, etc.) to produce those documents in their own specific and long-familiar print layouts. I also was able to guarantee fidelity between PDF and HTML renderings by deriving the HTML from the XSL-FO used for the PDF ... but that's another story.

I presented this in 2005 describing the publishing system I designed and implemented using multiple onion skins, one for each agency, around a common core: <http://web.archive.org/web/20071113054804/http://www.idealliance.org/proceedings/xml05/ship/18/Holman-18.HTML>http://web.archive.org/web/20071113054804/http://www.idealliance.org/proceedings/xml05/ship/18/Holman-18.HTML 



At 19/04/2026 21:32 +0000, Roger L Costello costello@xxxxxxxxx wrote:
>Hi Folks,
>
>Ken, thank you for your response. I appreciate it.
>
>Your message helped clarify an issue that, frankly, has eluded me for a long time.
>
>Up to now, I've been framing the question as:
>
>Which is a better way to design a system: declarative or imperative?
>
>But your message suggests that this may not be the right question.
>
>The real question seems to be something closer to this:
>
>How do you structure a system so that shared behavior is centralized, while variation is handled cleanly and locally?
>
>In your publishing example, the core XSLT defines the default behavior, and each client provides only a thin "outer layer" that overrides what needs to change. The core does not need to know how it is being used, and each client can specialize behavior without affecting others.
>
>That is a very different model from what I typically see in imperative systems, where variation often leads to conditionals, branching logic, and duplication scattered throughout the code.
>
>What strikes me is that this "onion skin" layering makes the declarative nature of XSLT much more visible. The benefit is not in a head-to-head comparison on a single task, but in how the system evolves as requirements diverge.
>
>In that light, I can see why a small example might fail to make the case, while a layered, multi-client system makes the advantage much clearer.
>
>This is a very helpful perspective--thank you.
>
>Best,
>Roger
><http://www.mulberrytech.com/xsl/xsl-list>XSL-List info and archive 
><http://lists.mulberrytech.com/unsub/xsl-list/96802>EasyUnsubscribe (<>by email) 


--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/s/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$50 (5 hours free!) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |