Re: [xml-dev] Transformational reciprocity (was [xml-dev] XML'sgreatest

[Fraser Goffin <goffinf@gmail.com>]

Whilst those of us who work as integrators quite naturally accept that
transformation between data formats is a given, that is not to say
that we shouldn't actively seek transformation avoidance policies
where-ever that is possible. Standardising exchanges between known
trading partners and between internal applications is often possible
and desirable and not only offers performance improvement but also
makes the interaction significantly less complex, and less complex =
fewer bugs = lower cost =... well, you get the idea.

On 29/04/2013, Simon St.Laurent <simonstl@simonstl.com> wrote:
> On 4/28/13 9:17 PM, David Lee wrote:
>> I agree only indirectly ... Why do I want transformations ? I don't
>> do it for fun.
>
> You do it for work.  If the transformations go away, so do a lot of
> jobs.  You seem to regard transformations as something you have to do,
> not something you want to do.
>
> What would be better to work on?
>
>> What are tools to enable clear descriptions ?  One way is clear and
>> concise specifications, one form of which is schema. There are other
>> ways like putting the two people who know each format side by side
>> and verbally exchanging the information
>
> Or by doing it iteratively, as the conversation grows, working with
> approaches that don't try to limit the frequency of conversation to big
> bangs passing as much information as possible at once.  (That is
> frequently the case in all these mere web applications using JSON, for
> instance.  Non-trivial, but workable.)
>
> Transformations defining paths from "yours" to "mine" are a surprisingly
> good basis for those conversations, certainly more easily versioned than
> "ours".
>
>  > ... that is if they can remember all the details perfectly.
>
> Doesn't it bother you that we actually let our tools reach the point
> where we just don't remember what our systems are doing?  I know it's
> not unusual, but it's a sign that automation has gone too far.
>
>> There certainly are other ways to
>> solve the problem, but the problem still requires clear understanding
>> of format and semantics, and a rich enough data model and toolset.
>
> Clear understandings are marginally possible under the best of
> circumstances.  Insisting on genuinely common semantics makes the tool
> set problems look small.
>
>> So IMHO transformations are not the advantage itself but rather the
>> means to an end.   One part of a bigger problem which the XML
>> ecosystem solves fairly well, certainly vastly better then JSON, and
>> IMHO better than any other ecosystem currently available.    But of
>> course by solving a big problem it suffers somewhat on simple
>> problems. oh well, cake and eat etc.
>
> XML likes to think it solves big problems.  After a decade and a half
> with it, I think markup has brilliantly solved big problems (and has
> been since GML and friends), but the layers on top of markup have been
> an extended effort in solving the wrong problems.  Since at least some
> customers want those problems solves, the ecosystem persists.
>
> Global understandings of vocabularies and content are about as good an
> idea as global variables, if that.  (For those tracking heresies, I
> think that brings me closer to Walter Perry's Standard Data Vocabularies
> Unquestionably Harmful than I've been in the past.)
>
> But yes, we seem to agree that XML is more transformable than other
> stuff, though I'm sure there's something I haven't found that's even
> better for transformations.
>
> Thanks,
> --
> 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
>
>