Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fwd: Transformative Programming: Flow-based, functional,and mo
 ---------- Forwarded message ---------- From: Dimitre Novatchev <dnovatchev@gmail.com> Date: Wed, Oct 16, 2013 at 10:43 AM Subject: Re: Transformative Programming: Flow-based, functional, and more To: "Simon St.Laurent" <simonstl@simonstl.com> The XPath Visualizer 2 (not yet made public), is a visual environment that allows the human user to import a variety of stylesheet modules and then use/evaluate the functions defined in these, connected in any (unpredictable) expressions. Initially I wrote this to use as an interpreter for FXSL -- also as a quick way to glue together the necessary functions and see if the expected results are produced -- before putting this code within an XSLT program. I believe this come close to the "human link" in the FBP ? Cheers, Dimitre On Wed, Oct 16, 2013 at 8: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. > > The easiest way to explain this is that different transformations can have > different requirements, different levels of expected precision, and > different capabilities for handling variation. > > If a transformation is a simple mathematical function, it's reasonable for > it to break if given textual arguments. On the other hand, if it's an input > cleaner that we regularly train to handle new situations, it's probably a > lot more flexible. In particular, if (as I suggest at the end) that > transformation is actually relying on a human rather than a microprocessor, > there may be far far more flexibility available. > > A flow makes it fairly easy to put more flexible transformations at the > beginning and end of the flow, or generally anywhere a "border crossing" > might happen. Transformations with more rigid expectations will likely lurk > in the middle of such flows, hidden away from communications challenges to > the extent possible. > > That allows a mix of styles and expectations to coexist. Code that requires > predictable inputs to work can have it, without demanding that everything > around it have the same expectations. Code that needs to interact with > humans or other chaotic systems can have its own flexibility. > > Perhaps most important, though, mapping how and where these interactions > take place should become much much easier. > > Does that tell the story any better? It leads to the next round or two or > what I'm planning to write, so I'd love to find weaknesses in it sooner > rather than later. > > Thanks, > Simon > >> On Wed, Oct 16, 2013 at 10:11 AM, Uche Ogbuji <uche@ogbuji.net >> <mailto:uche@ogbuji.net>> wrote: >> >> On Wed, Oct 16, 2013 at 8:41 AM, Peter Hunsberger >> <peter.hunsberger@gmail.com <mailto:peter.hunsberger@gmail.com>> >> wrote: >> >> Nice write up Simon. This seems more accepting of structured >> XML data management approaches than I've come to expect from you >> recently. Something going on or is this just an anomaly? >> >> >> I think you might have misread Simon in his posts challenging the >> XML community. He has never that I've seen put down XML's basic >> usefulness for semi-structured, open data expression. Your >> characterization as "structured XML data management approaches," >> however, is another kettle of fish, and not a way of putting it that >> I think communicates XML's strengths. >> >> Simon's main complaint has been with the culture of rigid >> schematics, and with the bleed-in of the imperative programmer's >> mindset into XML (notice that he gives a positive mention of XSLT >> and XProc, which at least in their initial forms stayed away from >> imperative style). It seems to me that this article continues his >> points consistently. >> >> -- >> Uche Ogbuji http://uche.ogbuji.net >> Founding Partner, Zepheira http://zepheira.com >> Author, Ndewo, Colorado http://uche.ogbuji.net/ndewo/ >> Founding editor, Kin Poetry Journal http://wearekin.org >> Editor & Contributor, TNB >> http://www.thenervousbreakdown.com/author/uogbuji/ >> http://copia.ogbuji.net http://www.linkedin.com/in/ucheogbuji >> http://twitter.com/uogbuji >> >> > > > -- > Simon St.Laurent > http://simonstl.com/ > > _______________________________________________________________________ > > XML-DEV is a publicly archived, unmoderated list hosted by OASIS > to support XML implementation and development. To minimize > spam in the archives, you must subscribe before posting. > > [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/ > Or unsubscribe: xml-dev-unsubscribe@lists.xml.org > subscribe: xml-dev-subscribe@lists.xml.org > List archive: http://lists.xml.org/archives/xml-dev/ > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php -- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Never fight an inanimate object ------------------------------------- To avoid situations in which you might make mistakes may be the biggest mistake of all ------------------------------------ Quality means doing it right when no one is looking. ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play ------------------------------------- Facts do not cease to exist because they are ignored. ------------------------------------- Typing monkeys will write all Shakespeare's works in 200yrs.Will they write all patents, too? :) ------------------------------------- I finally figured out the only reason to be alive is to enjoy it. -- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- Never fight an inanimate object ------------------------------------- To avoid situations in which you might make mistakes may be the biggest mistake of all ------------------------------------ Quality means doing it right when no one is looking. ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play ------------------------------------- Facts do not cease to exist because they are ignored. ------------------------------------- Typing monkeys will write all Shakespeare's works in 200yrs.Will they write all patents, too? :) ------------------------------------- I finally figured out the only reason to be alive is to enjoy it. 
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
