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

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

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/