To add my .01euro ... this one of the compelling reasons I wrote xmlsh (about the same era Norm was writing XProc)
is that the concept of pipelines was (being) lost in the monolithic cause of Huge Applications (mainly XSLT, but in my case it was XQuery ... or custom apps).
I belive the reasons were pragmatic ... that it simply was expensive to run pipelines (as seperate processes) so people started writing monolitic transformations.
By bringing pipelines back into the affordable realm ... the necessity to write huge single transforms instead of pipelines of smaller ones becomes a reasonable
tool again.
And with that the ability to debug in the small, to have edges that are very strict but middle pieces that are very flexable ... but still defined interfaces.
With xmlsh and xproc ... pipelines now can be structured data ... but the benefits of the Philosophy of unix pipelines can still be used.
http://www.xmlsh.org/Philosophy
----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org
From: Uche Ogbuji [mailto:uche@ogbuji.net]
Sent: Wednesday, October 16, 2013 1:23 PM
To: Simon St.Laurent
Cc: Peter Hunsberger; xml-dev@lists.xml.org
Subject: Re: [xml-dev] Transformative Programming: Flow-based, functional, and more
On Wed, Oct 16, 2013 at 9:57 AM, Simon St.Laurent <simonstl@simonstl.com> wrote:
On 10/16/13 11:40 AM, Peter Hunsberger wrote:
Simon's been pretty clear that data interchange via XML is all well and
good and that rigid standards can be a problem. However, that does get
to the essence of my question, where does the line between these two
divergent views get drawn? In particular, XSLT and XProc are useful
precisely because of the standardization and structure of their
particular XML formats (imperative or not)... Their very utility comes
with the cost that Simon often seems to disapprove of.
I suspect the reality is that Uche is right that I (at least think I) am still consistent with my earlier position, but a quick read of flow-based programming might seem to lead right back to the excessively structured
data models I regret.
I think that might be true of some of the approaches in the rebirth of flow-based programming, but I don't think it's axiomatically true. For example, you mention UNIX pipes, which involve breathtakingly unstructured
data (usually the only structure is the line break).
In my observation of 21st century FBP, people do at last seem aware that they should be simplifying and reducing the coupling of the packets between nodes. There was a time that the XML community seemed aware of
this as well, then in 2002 or so it all went haywire.
Peter, i think you and I are using "structured data" in a very different way. For me, an example of structured data is a relational tablespace, or a Java class. XML is semi-structured, and neither XSLT 1.x nor XProc
require anything I'd call strong structure. XSLT 2.x and 3.x can work efficiently with strong structure if you have it, but do not require it. Therefore I disagree with the notion that the utility of XSLT or XProc comes at the cost of structure. But that's
an old debate, circling around these parts for over a decade, and I'm not just now up for a big rehash.
--
