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@o...

<mailto:uche@o...>> wrote:

    On Wed, Oct 16, 2013 at 8:41 AM, Peter Hunsberger

    <peter.hunsberger@g... <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/