Re: [xml-dev] Transformative Programming: Flow-based, functional,and mor

["Simon St.Laurent" <simonstl@simonstl.com>]

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/