XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Transformative Programming: Flow-based, functional, and more

HI Simon,

Seems pretty coherent so far.  I think maybe part of your discomfort with REST in this context is that it requires standardization of the data interchanged across the boundaries?  If so, you may want to explore to what extent that is true since REST is an obvious target, even with the single Enterprise, at least at the higher levels of granularity (as evidenced by Amazon WS for example).  That could still give you a consistent story (and an interesting one in and of itself): the more granular you go the less formal the needs of the interchange format.  So, between Enterprises you (well at least some people) might even allow for XSD and their ilk, but within an application you get closer to Unix pipes. etc. 

Peter Hunsberger


On Wed, Oct 16, 2013 at 10: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/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS