[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Transformative Programming: Flow-based, functional,and mor

  • From: "Simon St.Laurent" <simonstl@simonstl.com>
  • To: Peter Hunsberger <peter.hunsberger@gmail.com>, "xml-dev@l..." <xml-dev@l...>
  • Date: Wed, 16 Oct 2013 11:57:26 -0400

Re:  Transformative Programming: Flow-based
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/


[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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.