Re: Specification of a transform.

Hi,

Thanks Tommie for pointing to those slides from our paper. It's great
that such resources are on line.

This is a complex and interesting topic.

I have reservations about most efforts to automate the relation
between specification (mapping) and transformation. Many times in my
experience such efforts are motivated by an interest not in solving
this problem, but in thinking about another one, namely how to capture
the analysis and specification in a form amenable to automated
processing (i.e., how to design and deploy a spec that can be compiled
into code). Designing and building a language to do a task can be more
fun than doing the task itself.

This doesn't mean that a domain-specific language for this purpose
will never be any use. If it's a good fit, and used by someone who
knows what they're doing (who could also do the task without it), it
could be very useful. If it's a poor fit, as so often, it may be more
effort and trouble than doing it by hand. Also, such an approach may
be good for 80% of the problem, while hiding and/or complicating the
last 20% - so using it is an entire skill in itself.

The method that Tommie has developed at Mulberry (and she should get
the credit as she did the mapping while I only implemented :-) works
well because it exposes the heart of the problem, not only in the
specification itself (which takes the form of a semi-formal document
that anyone knowledgeable about the process can read), but in the
communications between the party writing the spec and the party
writing the code. Think of it as a variety of pair programming, if you
like. It may or may not be very "agile" depending on the
organization's and the team's tolerance for risk and chaos on the way
to order. Yet even when not very agile, it tends to lowers both risk
and elapsed time (as Tommie points out) in comparison to having one
person do both jobs without a formal spec at all. Especially if the
team is experienced.

Sometimes it's also very useful to throw XSpec into the mix, as the
mapper can often write (and run) XSpec instances for unit testing, or
at least check them for correctness.

Mike also points out something interesting and important, namely that
a person who knows the data and problem and can therefore write a good
spec for a transformation will often make a better XSLT programmer
than a "programmer". In my experience, often these people haven't
learned to write XSLT (or much of anything else) mainly (or only)
because they think of themselves as experts in their domain, but "not
programmers". Put them to work with someone who can show how their
specifications translate into elegant code, and sometimes they will
surprise themselves with what they are not only able, but willing, to
learn. The person who writes the map for one transformation turns
around and writes code for another. This is a great way to identify
talented people and train them in XSLT.

It should be needless to point out that working this way demands a
fairly high level of maturity from everyone involved. In this case,
maturity translates largely into "willingness to listen and work
respectfully with others, who may know things I don't".

Cheers, Wendell

Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^


On Wed, Sep 11, 2013 at 5:12 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>>
>>> Which raises the issue, if a non XSLT programmer is specifying,
>>> how might he/she do it, without those XSLT skills?
>>
>> From http://www.mulberrytech.com/papers/MappingTransformations/slide009.html:
>>
>> * Understand both source and target data
>> * Ability to articulate complex relationships
>>    - clear to programmer
>>    - clear to content-owner
>> * Strong analytical skills
>> * XSLT expertise is not required!
>>
>> A subject matter expert who groks XML structures can be better for this
>> than a programmer who groks XSLT but not the data.
>>
>
> In my experience a subject matter expert able to articulate such a specification clearly will learn XSLT much faster than the average programmer coming from imperative languages.
>
> Michael Kay
> Saxonica